Home > Articles > Cisco Certification > CCIE > CCIE Self-Study: Security Protocols

CCIE Self-Study: Security Protocols

  • Sample Chapter is provided courtesy of Cisco Press.
  • Date: Oct 28, 2005.

Chapter Description

This chapter covers some of today's most widely used technologies that enable network administrators to ensure that sensitive data is secure from unauthorized sources. Standards such as IP Security (IPSec) and encryption standards are covered, as are all the fundamental foundation topics you need to understand to master the topics covered in the CCIE Security written exam.

Encryption Technology Overview

When prominent Internet sites, such as http://www.cnn.com, are exposed to security threats, the news reaches all parts of the globe. Ensuring that data crossing any IP network is secure and not vulnerable to threats is one of today's most challenging tasks in the IP storage arena (so much so that Cisco released an entirely new CCIE for the storage networking certification track).

Major problems for network administrators include the following:

  • Packet snooping (eavesdropping)— When intruders capture and decode traffic, obtaining usernames, passwords, and sensitive data such as salary increases for the year.
  • Theft of data— When intruders use sniffers, for example, to capture data over the network and steal that information for later use.
  • Impersonation— When an intruder assumes the role of a legitimate device but, in fact, is not legitimate. The intruder efficiently assumes the role of an authorized user.

The solution to these and numerous other problems is to provide encryption technology to the IP community and enable network administrators to ensure that data is not vulnerable to any form of attack or intrusion. This ensures that data is confidential, authenticated, and has not lost any integrity during the routing of packets through an IP network.

Encryption (user data that is encrypted will require decryption also) is defined as the process by which plain data is converted into ciphered data (a system in which plain-text data is arbitrarily substituted according to a predefined algorithm known as cipertext) so that only the intended recipient(s) can observe the data. Encryption ensures data privacy, integrity, and authentication.

Figure 4-4 displays the basic methodologies behind data encryption.


Figure 4-4 Encryption Methodologies

Figure 4-4 demonstrates the basic principles of data encryption, including the following:

  1. User data is forwarded over the network.

  2. Data (clear text) is modified according to a key. The key is a sequence of digits that decrypts and encrypts messages. Each device has three keys:

    • A private key used to sign messages that is kept secret and never shared.
    • A public key that is shared (used by others to verify a signature).
    • A shared secret key that is used to encrypt data using a symmetric encryption algorithm, such as DES. Typically, however, a device has two keys, a symmetric key and an asymmetric key. The symmetric key is a shared secret that is used to both encrypt and decrypt the data. The asymmetric key is broken into two parts, a private key and a public key.
  3. A mathematical formula is applied to scramble the data. In Figure 4-4, the mathematical formula is applied during Step 2.

  4. The data flows throughout the network and can be decrypted only if the correct key and algorithm are applied.

Encryption can take place at the application layer, the network layer, or the data link layer. Be aware of the following encryption technologies for the CCIE Security written exam:

  • Data Encryption Standard (DES)
  • Triple DES (3DES)
  • Advanced Encryption Standard (AES)
  • IP Security (IPSec)

Cisco IOS routers support the following industry standards to accomplish network layer encryption:

  • DES/3DES
  • AES
  • MD5
  • Diffie-Hellman exchange
  • IPSec

DES and 3DES

DES is one of the most widely used encryption methods. DES turns clear-text data into cipher text with an encryption algorithm. The receiving station will decrypt the data from cipher text into clear text. The shared secret key is used to derive the session key, which is then used to encrypt and decrypt the traffic.

Figure 4-5 demonstrates DES encryption.


Figure 4-5 DES Encryption Methodologies

Figure 4-5 demonstrates the PC's clear-text generation. The data is sent to the Cisco IOS router, where it is encrypted with a shared key (remember, the shared secret key is used to derive the session key, which is then used to encrypt and decrypt the traffic) and sent over the IP network in unreadable format until the receiving router decrypts the message and forwards it in clear-text form.

DES is a block cipher algorithm, which means that DES performs operations on fixed-length data streams. DES uses a 56-bit key to encrypt 64-bit datagrams.

DES is a published, U.S. government-standardized encryption method; however, it is no longer a U.S. government-approved encryption algorithm.

3DES is the DES algorithm that performs three times (3 x 3 x encryption and 3 x decryption) sequentially (although there are some variations as well). Three keys are used to encrypt data, resulting in a 168-bit encryption key.

3DES is an improved encryption algorithm standard and is summarized as follows:

  1. The sending device encrypts the data with the first 56-bit key.
  2. The sending device decrypts the data with the second key, also 56 bits in length.
  3. The sending device encrypts for a final time with another 56-bit key.
  4. The receiving device decrypts the data with the first key.
  5. The receiving device then encrypts the data with the second key.
  6. Finally, the receiving device decrypts the data with the third key.

A typical hacker uses a Pentium III computer workstation and takes approximately 22 hours to break a DES key. In the case of 3DES, the documented key-breaking times are approximately 10 billion years when 1 million PC III computers are used. Encryption ensures that information theft is difficult.

Encryption can be used to enable secure connections over the LAN, WAN, and World Wide Web.

The end goal of DES/3DES is to ensure that data is confidential by keeping data secure and hidden. The data must have integrity to ensure that it has not been modified in any form, and be authenticated by ensuring that the source or destination is indeed the proper host device. Another encryption standard in common use today is widely regarded as the new industry standard, namely AES.

Advanced Encryption Standard

AES, developed by Joan Daemen and Vincent Rijmen, is a new encryption standard and is considered a replacement for DES. The U.S. government made AES a standard in May 2002, and the National Institute of Standards and Technology (NIST) has adopted AES. AES provides key lengths for 128, 192, and 256 bits.

AES supports Cipher Blocks Chaining (CBC), which circumvents one of the problems with block algorithms in that two equal plain-text blocks will generate the same two equal ciphertext blocks. With CBC, the key is applied to Plain(1) to get Cipher(1). Then, Cipher(1) is used as the key against Plain(2) to get Cipher(2), which is used as the key against Plain(3) to get Cipher(3), continuing on until the end.

AES is designed to be more secure than DES through the following enhancements:

  • A larger key size.
  • Ensures that the only known approach to decrypt a message is for an intruder to try every possible key.
  • Has a variable key length; the algorithm can specify a 128-bit key (the default), a 192-bit key, or a 256-bit key.

For more details on Cisco IOS support for AES, visit http://cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080110bb6.html.

Message Digest 5 and Secure Hash Algorithm

Several hashing algorithms are available. The two discussed here are MD5 and SHA. There is a slight, unknown difference between SHA and SHA-1. NSA released SHA and then later discovered a flaw (undisclosed). NSA fixed it, and called the new version SHA-1. In this guide, SHA refers to SHA-1 also.

Message hashing is an encryption technique that ensures that a message or data has not been tampered with or modified. MD5 message hashing is supported on Cisco IOS routers. A variable-length message is taken, the MD5 algorithm is performed (for example, the enable secret password command), and a final fixed-length hashed output message called a message digest is produced. MD5 is defined in RFC 1321.

Figure 4-6 displays the MD5 message operation.


Figure 4-6 MD5 Operation

Figure 4-6 displays the simple clear-text message, "Hello, it's me," which can be of any variable length. This message is sent to the MD5 process, where the clear-text message is hashed and a fixed-length, unreadable message is produced. The data can include routing updates or username/password pairings, for example. MD5 produces a 128-bit hash output.

SHA is the newer, more secure version of MD5, and Hash-based Message Authentication (HMAC) provides further security with the inclusion of a key exchange. SHA produces a 160-bit hash output, making it even more difficult to decipher. SHA follows the same principles as MD5 and is considered more CPU-intensive.

For more details on Cisco IOS encryption capabilities, visit the following website:



The Diffie-Hellman protocol allows two parties to establish a shared secret over insecure channels, such as the Internet. This protocol allows a secure shared key interchange over the public network, such as the World Wide Web, before any secure session and data transfer is initiated. Diffie-Hellman ensures that, by exchanging just the public portions of the key, both devices can generate a session and ensure that data is encrypted and decrypted by valid sources only. Only public keys (clear text) are exchanged over the public network. Using each device's public key and running the key through the Diffie-Hellmann algorithm generates a common session key. Only public keys will ever be exchanged.

Figure 4-7 displays the Diffie-Hellman exchange between Cisco routers, R1 and R2.


Figure 4-7 Diffie-Hellman Key Exchange

The Diffie-Hellman key exchange takes place over a public domain. With the private key kept secret, it is very difficult for an outside intruder to generate the same key, and the private key is never exchanged over the public domain, making the process very secure.

The shared prime numbers (mathematically, a prime number is any positive integer greater than 1 and divisible without a remainder only by 1 and itself) have a special relationship that makes agreeing on a shared secret possible. An analogy would be to have two milkshake blenders making a chocolate milkshake, but with one blender supplied with apples and the other with oranges. The Diffie-Hellman algorithm is the secret ingredient that, when mixed in with both blenders, produces the chocolate milkshake. Remember, it really is a superb algorithm.

IP Security

IPSec provides security services at the IP layer by enabling a system to select required security protocols, determine the algorithm(s) to use for the service(s), and put in place any cryptographic keys required to provide the requested services.

—RFC 2401, "Security Architecture for the Internet Protocol"

IPSec is a defined encryption standard that encrypts the upper layers of the OSI model by adding a new predefined set of headers. IPSec is not just an encryption standard; IPSec provides a variety of other services, as discussed in this section. A number of RFCs defined IPSec.

IPSec is a mandatory requirement for IP version 6 (IPv6 is not covered in the examination). IPSec ensures that the network layer of the OSI model is secured. In TCP/IP's case, this would be the IP network layer. The two IPSec frame formats available, Authentication Header (AH) and Encapsulating Security Payload (ESP), both have protocol numbers assigned to them. They are shimmed in between IP and transport. (The protocol number says to give the datagram to AH or ESP, each of which has a next protocol number that eventually delivers the datagram to TCP or UDP or whatever else might be at the higher layer, such as OSPF.) Therefore, IPSec ensures that the data and headers above the network layer are secured.

IPSec can be configured in two protection modes, which are commonly referred to as security associations (SA). These modes provide security to a given IP connection. The modes are as follows (you have to use IPSec in tunnel mode if you want to obscure the network layer):

  • Transport mode— Protects payload of the original IP datagram; typically used for end-to-end sessions
  • Tunnel mode— Protects the entire IP datagram by encapsulating the entire IP datagram in a new IP datagram

An SA is required for inbound and outbound connections. In other words, IPSec is unidirectional. IKE, discussed in this chapter, allows for bidirectional SAs.

Figure 4-8 displays the extension to the current IP packet frame format for both transport and tunnel modes.


Figure 4-8 IPSec Protection Modes

The Encapsulating Security Payload (labeled IPSec header in Figure 4-8) can be of [the] form:

  • ESP
  • AH

Each of these is discussed in the following sections.

Encapsulating Security Payload

The ESP security service is defined in RFC 2406. ESP provides a service to the IP data (payload), including upper-layer protocols such as TCP. The destination IP number is 50. The ESP header is located between the user data and original IP header, as displayed in Figure 4-9.


Figure 4-9 ESP Header

ESP does not encrypt the original IP header (when in transport mode), and encrypts only the IP data by placing a header in between the original IP header and data. ESP provides data confidentiality, data integrity, and data origin authentication. ESP also prevents replay attacks. Replay attacks can include intruders capturing a valid packet and replaying it over the network in an attempt to get a packet conversation between an illegal and legal host.

In tunnel mode ESP, the original IP datagram is placed in the encrypted portion of the Encapsulating Security Payload and that entire ESP frame is placed within a datagram that has unencrypted IP headers. The information in the unencrypted IP headers is used to route the secure datagram from origin to destination. An unencrypted IP routing header might be included between the IP header and the Encapsulating Security Payload.

ESP does not protect the IP header and cannot detect any alternations during packet delivery.

Figure 4-10 displays the frame formats when ESP is applied.


Figure 4-10 ESP Frame Format

The Security Parameters Index (SPI) is an arbitrary 32-bit value that, in combination with the destination IP address and security protocol (ESP), uniquely identifies the SA for this datagram.

The Sequence Number, an unsigned 32-bit field, contains a monotonically increasing counter value. It is mandatory and is always present, even if the receiver does not elect to enable the antireplay service for a specific SA. PAD or padding is used when the frame needs to meet the minimum frame size formats. The PAD Length defines the length of padding used. Padding is used for a number of reasons. For example, padding can ensure that the minimum frame size is set so that packets are not discarded because they are too small. Padding is typically all binary ones (1111. . .) or zeros (0000. . .). The sequence number ensures that no intruder or intruders can replay data transactions by using any form of attack mechanisms.

The Next Header is an 8-bit field that identifies the type of data contained in the Payload Data field. The IP Data field contains the data to be sent. The Authentication Data field is a variable-length field containing an Integrity Check Value (ICV) computed over the ESP packet minus the Authentication Data.

Authentication Header

AH is described in RFC 2402. The IP destination protocol is 51. Figure 4-11 highlights the fields in the IP datagram that are encrypted (data is not encrypted) and authenticated. Note that not all fields, such as the Time to Live fields, are encrypted.


Figure 4-11 AH Header (Tunnel Mode)

Following is a description of an AH packet:

  • Next Header, an 8-bit field, identifies the type of the next payload after the Authentication Header.
  • The Payload Length field is an 8-bit field specifying AH's length in 32-bit words (4-byte units), minus 2.
  • The Reserved field is a 16-bit field reserved for future use. It must be set to 0.
  • The SPI is an arbitrary 32-bit value that, in combination with the destination IP address and security protocol (AH), uniquely identifies the SA for this datagram.

AH can operate in transport or tunnel mode; however, unlike ESP, AH also protects fields in the outer IP header (in transport mode, this is the original IP header; in tunnel mode, this is the newly added IP header), which are normally considered nonvariable. AH ensures that if the original IP header has been altered, the packet is rejected. The protection mechanism thereby with AH is authentication only.

Before you take a look at how IPSec is enabled on Cisco routers, you need to understand how keys are exchanged between secure devices to ensure that data is not compromised. IPSec ensures that once an IPSec tunnel is created, the keys are modified so that intruders cannot replicate the keys and create IPSec tunnels to insecure locations. A recent study showed that a network of computer hackers was able to decipher a DES-encrypted message in just a day. (For details on this study please download ants.dif.um.es/~humberto/asignaturas/v30/docs/CryptographyFAQ.pdf.)

In IPSec, key exchange is provided by Internet Key Exchange (IKE).

Internet Key Exchange

In IPSec, an SA between any two devices will contain all relevant information, such as the cryptographic algorithm in use. A cryptographic algorithm is the product of the science of cryptography. This field of science includes the exact details of encryption algorithms, digital signatures, and key agreement algorithms.

A simple two-router network requires two SAs, one for each router. (IPSec requires one SA on each router for two-way communication.)

Clearly, for a large network, this would not scale. IKE offers a scalable solution to configuration, and key exchange management.

IKE was designed to negotiate and provide authenticated keys in a secure manner. IKE has two phases. In phase I, the cryptographic operation involves the exchange of a master secret where no security is currently in place. IKE phase I is primarily concerned with establishing the protection suite for IKE messages. Phase I operations are required infrequently and can be configured in two modes of operation—aggressive mode and main mode.

Aggressive mode eliminates several steps during IKE authentication negotiation phase I between two IPSec peers. Aggressive mode is faster than main mode but not as secure. Aggressive mode is a three-way packet exchange, while main mode is a six-way packet exchange.

IKE can be configured in aggressive mode or main mode (not both). Aggressive mode is a less-intensive process that requires only three messages to establish a tunnel, versus the six messages required in main mode. Aggressive mode is typically used in remote-access VPN environments.

IKE Phase I Message Types 1-6

IKE phase I completes the following tasks:

  • Main mode negotiates IKE policy (message types 1 and 2). Information exchanges in these message types include IP addresses. Proposals, such as Diffie-Hellman group number and encryption algorithm, are also exchanged here. All messages are carried in UDP packets with a destination UDP port number of 500. The UDP payload comprises a header, an SA payload, and one or more proposals. Message type 1 offers many proposals, and message type 2 contains a single proposal. For message type 2, it is the single proposal and transform that the responder wishes to accept.
  • Performs authenticated Diffie-Hellman (DH) exchange. Message types 3 and 4 carry out the DH exchange. Message types 3 and 4 contain the key exchange payload, which is the DH public value and a random number (called a nonce). Message types 3 and 4 also contain the remote peer's public key hash and the hashing algorithm. A common session key created on both ends, and the remaining IKE messages exchanged from here are encrypted. If perfect forward secrecy (PFS) is enabled, another DH exchange will be completed. The public key hash and hashing algorithm are sent only if the authentication mechanism is public key encryption.
  • Protects IKE peers' identities—identities are encrypted. Message types 5 and 6 are the last stage before traffic is sent over the IPSec tunnel. Message type 5 allows the responder to authenticate the initiating device. Message type 6 allows the initiator to authenticate the responder. These message types are not sent as clear text. Message types 5 and 6 will now be encrypted using the agreed-upon encryption methods established in message types 1 and 2.

After IKE phase I is completed, each peer or router has authenticated itself to the remote peer, and both have agreed on the characteristics of all the SA parameters (IKE parameters).

Figure 4-12 summarizes the key components of IKE phase I and some of the possible permutations available on Cisco IOS routers.


Figure 4-12 IKE Phase I Summary

The first message exchanged offers the remote router a choice of IPSec parameters, such as encryption algorithm, 3DES, MD5, and DH group number, for example. The first message's aim is to negotiate all SA policies.

In the second message (type 2), the responding device indicates which of the IPSec parameters it wants to use in the tunnel between the two devices, including the information required to generate the shared secret and provide authentication details. The final message (type 3; until now no encryption is enabled) authenticates the initiator.

After IKE phase I is complete, IKE phase II is initiated. As discussed in the following section, IKE phase II negotiation has three message types.

IKE Phase II Message Types 1-3

IKE phase II negotiates the SA and the keys that will be used to protect the user data. IKE phase II messages occur more frequently, typically every few minutes, whereas IKE phase I messages might occur once a day. On most Cisco IOS devices, the timeout is 1 hour.

IP datagrams that exchange IKE messages use UDP (connectionless) destination port 500.

Phase II negotiations occur in a mode called Oakley quick mode and have three different message exchanges. Quick mode can be the following:

  • Without key exchange— No PFS is enabled.
  • With key exchange— When PFS is enabled, the DH algorithm is run once more to generate the shared secret.

Message type 1 allows the initiator to authenticate itself, and selects a random (nonce) number and proposes an SA to the remote peer. Additionally, a public key is provided (can be different than a key exchanged in IKE phase I). IKE phase II message type 2 allows the responding peer to generate the hash. Message type 2 allows the responder to authenticate itself, and selects a random number and accepts the SA offered by the initiating IPSec peer. A hash is intended as a collision-resistant function, as required for the hashing of information prior to application of a signature function.

IKE message type 3 acknowledges information sent from quick mode message type 2 so that the phase II tunnel can be established.

Now that all the required data has been exchanged, the initiating IPSec router, or peer, sends a final phase I message with the hash of the two random numbers generated and the message ID. The responder needs to verify the hash before data can be protected.

Figure 4-13 summarizes the key components of IKE phase II.


Figure 4-13 IKE Phase II Summary

Figure 4-14 displays a typical IKE phase I/II completion.


Figure 4-14 IKE Phase I/II

Table 4-5 summarizes the key components of IKE phases I and II.

Table 4-5. IKE Phases I and II



IKE phase I

Authenticates IPSec peers

Negotiates matching policy to protect IKE exchange

Exchanges keys via Diffie-Hellman

Establishes the IKE SA

IKE phase II

Negotiates IPSec SA parameters by using an existing IKE SA

Establishes IPSec security parameters

Periodically renegotiates IPSec SAs to ensure security and that no intruders have discovered sensitive data

Can also perform optional additional Diffie-Hellman exchange

IKE requires that all information exchanges be encrypted and authenticated. In addition, IKE is designed to prevent the following attacks:

  • Denial of service— When messages are constructed with unique cookies that can be used to identify and reject invalid messages.
  • Man in the middle— Prevents the intruder from modifying messages and reflecting them back to the source or replaying old messages.

Table 4-6 summarizes the key terms and concepts used in IPSec terminology.

Table 4-6. Summary of IPSec Terms and Concepts



Internet Key Exchange (IKE)

Provides utility services for IPSec, such as authentication of peers, negotiation of IPSec SAs, and encryption algorithms. IKE operates over the assigned UDP port 500.

Security associations (SAs)

Connections between IPSec peers. Each IPSec peer maintains an SA database containing parameters, such as peer addresses, security protocols, and a Security Parameter Index (SPI). An SA is unidirectional, and two SAs are required to form a complete tunnel.

Data Encryption Standard (DES)

Encrypts and decrypts data. It is not considered a strong algorithm and was replaced by 3DES. DES supports only a 56-bit key. 3DES supports three 56-bit keys, or a 168-bit key.

Triple DES (3DES)

A variant of DES that is a much stronger encryption method and uses a 168-bit key.

Advanced Encryption Standard (AES)

A new standard that supports 128-, 192-, and 256-bit key lengths; considered a replacement for DES.

Message Digest version 5 (MD5)

A hash algorithm (128 bit) that takes an input message (of variable length) and produces a fixed-length output message. IKE uses MD5 for authentication purposes.

Secure Hash Algorithm (SHA-1)

A hash algorithm (160 bit) that signs and authenticates data. It is stronger than MD5 but more CPU-intensive and, therefore, slower.

RSA signatures

RSA is a public-key encryption system used for authentication. Users are assigned both private and public keys. The private key is not available to the public and decrypts messages created with the public key. To obtain a legitimate signature, you need to have a Certificate Authority sign your public key, making it a certificate.

Certificate Authority (CA)

A trusted third party whose purpose is to sign certificates for network entities that it has authenticated.

Diffie-Hellman (DH)

Algorithm that is used to initiate and secure the session between two hosts, such as routers.

Encapsulating Security Payload (ESP)

ESP (transport mode) does not encrypt the original IP header, and only encrypts the IP data by placing a header in between the original IP header and data. ESP (tunnel and transport modes) provides data confidentiality, data integrity, and data origin authentication.

Figure 4-15 displays the flow chart before any data can be transferred between two IPSec peers.


Figure 4-15 IPSec Flow

In Figure 4-15, interesting traffic (or traffic from an end user, for example, defined in the ACLs) triggers IKE phases I and II followed by the establishment of the IPSec tunnel. After the IPSec tunnel is established, the data can be transferred. After the data is transferred, the IPSec tunnel is closed. You can tunnel any form of data across the IPSec tunnel, such as IP, Novel IPX, or AppleTalk.

Cisco IOS IPSec Configuration

To enable IPSec between Cisco IOS routers, the following steps are required:

Step 1. Enable Internet Security Association Key Management Protocol (ISAKMP) with the IOS command crypto isakmp enable.

This step globally enables or disables ISAKMP at your peer router.

ISAKMP is enabled by default (ACLs define what interesting traffic will be encrypted using defined ACLs).

Step 2. Define an ISAKMP policy, a set of parameters used during ISAKMP negotiation:

         crypto isakmp policy 

You will enter config-isakmp command mode.

Options available include the following:

authentication {rsa-sig | rsa-encr | pre-share}
  encryption {des} {3des} {aes}
  group 1 2 5
  hash {md5 | sha}
  lifetime seconds

This command invokes the ISAKMP policy configuration (config-isakmp) command mode. While in ISAKMP policy configuration command mode, the following commands are available to specify the parameters in the policy:

  • encryption (IKE policy)— The default is 56-bit DES-CBC. To specify the encryption algorithm within an IKE policy, options are des, 3des, or aes.
  • hash (IKE policy)— The default is SHA-1. To specify the hash algorithm within an IKE policy, options are sha, which specifies SHA-1 (HMAC variant) as the hash algorithm, or md5, which specifies MD5 (HMAC variant) as the hash algorithm. Hashed Message Authentication Code (HMAC) uses keyed message digest functions to authenticate a message. The technique used in IPSec is defined in RFC 2104.
  • authentication (IKE policy)— The default is RSA signatures. To specify the authentication method within an IKE policy, options are rsa-sig, which specifies RSA signatures as the authentication method; rsa-encr, which specifies RSA encryption as the authentication method; or pre-share, which specifies preshared keys as the authentication method.
  • group {1 | 2}— The default is 768-bit Diffie-Hellman. To specify the DH group identifier within an IKE policy, options are 1, which specifies the 768-bit DH group, or 2, which specifies the 1024-bit DH group. DH group 5 is also available (1536-bit).
  • lifetime (IKE policy)— The default is 86,400 seconds (once a day). To specify the lifetime of an IKE SA, use the ISAKMP lifetime policy configuration command. If two IPSec peers share different lifetime values, the chosen value is the shortest lifetime.
Step 3.

Set the ISAKMP identity (can be IP address or host name based):

         crypto isakmp 
         identity {address | hostname}

Step 4. Define transform sets (Phase II).

A transform set represents a combination of security protocols and algorithms. During the IPSec SA negotiation, the peers agree to use a particular transform set for protecting a particular data flow.

To define a transform set, use the following commands, starting in global configuration mode:

         crypto ipsec transform-set
         transform-set-name transform1 [transform2 [transform3]]
This command puts you into the crypto transform configuration mode. Then, define the mode associated with the transform set:

Router(cfg-crypto-tran)# mode [tunnel | transport]

The default is tunnel.

Step 5.

Define crypto maps, which tie the IPSec policies and SAs together:

         crypto map 
         name seq method [dynamic 

The following typical configuration scenario illustrates the IPSec configuration tasks with a two-router network. Figure 4-16 displays two routers configured with the networks and, respectively. Suppose that the Frame Relay cloud is an unsecured network and you want to enable IPSec between the two routers, R1 and R2.


Figure 4-16 Typical IPSec Topology Between Two Remote Routers

The network administrator has decided to define the following ISAKMP parameters:

  • MD5.
  • Authentication will be via preshared keys.
  • The shared key phrase is CCIE.
  • IPSec mode is transport mode.

To start, configure IKE on Router R1. Example 4-11 displays the IKE configuration on R1. Remember that IKE policies define a set of parameters to be used during IKE negotiation. (Note that in Cisco IOS 12.2T and later, the commands have different options.)

Example 4-11. R1 IKE Configuration

   crypto isakmp policy 1
 hash md5
 authentication pre-share
crypto isakmp key CCIE address

R1 is configured to use the MD5 algorithm, and the authentication method is defined as preshared. The preshared key value (password) is CCIE, and the remote IPSec peer's address is (R2 serial link to R1 in Figure 4-16).

Following the IKE configuration, you can configure IPSec parameters. Example 4-12 enables the IPSec configuration parameters.

Example 4-12. IPSec Configuration

crypto ipsec transform-set anyname esp-des esp-sha-hmac mode transport
crypto map anyname1 1 ipsec-isakmp
 set peer                                                     
 set security-association lifetime seconds 900
 set transform-set anyname
   match address 100                                 
access-list 100 permit ip

The transform-set command defines an acceptable combination of security protocols and algorithms. This example applies ESP-DES (ESP with the 56-bit DES encryption algorithm) and ESP with the SHA (HMAC variant) authentication algorithm. (Note that you can also apply 3DES or AES to provide even stronger encryption methods.) The next-hop peer address is defined, and access-list 100 defines what traffic will be encrypted. In Figure 4-16, only IP traffic sourced from destined for is sent across the IPSec tunnel.

Example 4-13 displays the configuration on R2.

Example 4-13. R2 IKE and IPSec Configuration

! IKE configuration
crypto isakmp policy 1
 hash md5
 authentication pre-share
crypto isakmp key CCIE address
crypto ipsec transform-set anyname esp-des esp-sha-hmac
 mode transport
!IPSec configuration
crypto map anyname1 1 ipsec-isakmp
 set peer
 set security-association lifetime seconds 900
 set transform-set anyname
 match address 100
!Access list defines traffic to be encrypted or interesting traffic
access-list 100 permit ip  

Notice that the routers have mirrored ACLs. This ensures that when encrypted data is received from a source, such as R1, the corresponding IPSec peer router, R2, enables encryption in the reverse direction. For example, when traffic from the network residing on Router R1 is sent across, destined for R2's Ethernet network, the IP subnet, R2 must have a corresponding ACL permitting traffic from the locally connected Ethernet segment,, to the remote network, the IP subnet on R1, This is referred to as mirrored ACLs.

Example 4-13 configures R2 to peer to R1 and only encrypt traffic sourced from destined for R1's Ethernet network, The crypto predefined map name is anyname1.

Finally, you must apply a previously defined crypto map in Example 4-12. The defined crypto map name is anyname1 in this example, so apply that configuration to the interface. The IOS command that applies the crypto map to an interface is as follows (in config-interface mode):

   crypto map anyname1

Example 4-14 assigns the serial links on R1 and R2 to the crypto map name anyname1 and assigns the crypto map to interface Serial 0/0 on R1/R2.

Example 4-14. Serial Links and crypto map on R1/R2

Hostname R1
interface Serial0/0
 ip address
 crypto map anyname1                                                       
Hostname R2
interface Serial0/0
 ip address
 crypto map anyname1                                                        

To display the status of all crypto engine active connections, use the IOS command show crypto engine connections active.

Example 4-15 displays the current active crypto engines on R1.

Example 4-15. show crypto engine connections active on R1

R1#show crypto engine connections active
 ID Interface   IP-Address    State  Algorithm          Encrypt Decrypt
 1 Serial0/0 set    HMAC_MD5+DES_56_CB       5       5     

R1 has an IPSec peer connection to R2, through the Serial0/0 interface ( The algorithm in use is defined and displayed, as well.

To view the crypto map configuration from the PRIV EXEC, use the IOS command show crypto map.

Example 4-16 displays the configuration present on R1.

Example 4-16. show crypto map on R1

R1#show crypto map
Crypto Map "anyname1" 1 ipsec-isakmp
 Peer =
 Extended IP access list 100
access-list 100 permit ip  
 Current peer:
 Security association lifetime: 4608000 kilobytes/180 seconds
 PFS (Y/N): N
 Transform sets={ anyname, }
 Interfaces using crypto map anyname1:

Example 4-16 displays the fact that the crypto map named "anyname1" is peered to a remote router,, and the access-list 100 defines what traffic will be encrypted across the tunnel.

IPSec is a large field, and to define every possible scenario would require a book in itself. What is presented in this guide is a conceptual overview of IPSec and a common configuration example. For more extensive details, visit:

For the CCIE Security written exam, expect to see scenarios of the variant presented in Figure 4-16 and questions on terminology and the main characteristics of IPSec.

Table 4-7 defines some key IPSec configuration show and debug commands available on Cisco IOS routers.

Table 4-7. IOS IPSec Configuration, Show, and Debug Commands



crypto map map-name seq-num ipsec-isakmp [dynamic dynamic-map-name] [discover]

Creates a crypto map entry.

crypto ipsec transform-set transform-set-name transform1 [transform2 [transform3]]

Defines a transform set, an acceptable combination of security protocols and algorithms. This is IKE phase II.

match address [access-list-id | name]

This command is required for all static crypto map entries. Defines interesting traffic.

crypto dynamic-map dynamic-map-name dynamic-seq-num

Use dynamic crypto maps to create policy templates that can be used when processing negotiation requests for new SAs from a remote IPSec peer, even if you do not know all the crypto map parameters.

crypto ca authenticate name

This command is required when you initially configure CA support at your router.

crypto ca identity name

Use this command to declare a CA.

crypto isakmp enable

Globally enables IKE at your local router.

Show crypto engine connection active

Displays phase I and II SA and traffic sent.

authentication {rsa-sig | rsa-encr | pre-share}

Specifies the authentication method within an IKE policy.

show crypto ipsec sa

Displays the settings used by current SAs to declare a CA.

show crypto map

Displays the crypto map configuration.

show crypto isakmp sa

Displays all current IKE SAs at a peer.

debug crypto engine

Displays debug messages about crypto engines, which perform encryption and decryption.

debug crypto ipsec

Displays IPSec events.

debug crypto pki messages

Displays debug messages for the details of the interaction (message dump) between the CA and the router.

debug crypto isakmp

Enables global IKE debugging.

6. Certificate Enrollment Protocol | Next Section Previous Section

Cisco Press Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Cisco Press and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Cisco Press products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@ciscopress.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by Cisco Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.ciscopress.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020