CCIE Self-Study: Security Protocols

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:

http://www.cisco.com/en/US/products/sw/iosswrel/products_ios_cisco_ios_software_releases.html

Diffie-Hellman

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

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 
         priority

      

You will enter config-isakmp command mode.

Options available include the following:

Router(config-isakmp)#?
authentication {rsa-sig | rsa-encr | pre-share}
  default
  encryption {des} {3des} {aes}
  exit
  group 1 2 5
  hash {md5 | sha}
  lifetime seconds
  no

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 
         dynamic-map-name]

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 131.108.100.0/24 and 131.108.200.0/24, 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 131.108.255.2
   

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 131.108.255.2 (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 131.108.255.2                                                     
 set security-association lifetime seconds 900
 set transform-set anyname
 
   match address 100                                 
!
access-list 100 permit ip 131.108.100.0 0.0.0.255 131.108.200.0 0.0.0.255

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 131.108.100.0 destined for 131.108.200.0/24 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 131.108.255.1
!
crypto ipsec transform-set anyname esp-des esp-sha-hmac
 mode transport
!IPSec configuration
crypto map anyname1 1 ipsec-isakmp
 set peer 131.108.255.1
 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 131.108.200.0 0.0.0.255 131.108.100.0 0.0.0.255  

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 131.108.100.0/24 residing on Router R1 is sent across, destined for R2's Ethernet network, the IP subnet 131.108.200.0/24, R2 must have a corresponding ACL permitting traffic from the locally connected Ethernet segment, 131.108.200.0/24, to the remote network, the IP subnet on R1, 131.108.100.0/24. This is referred to as mirrored ACLs.

Example 4-13 configures R2 to peer to R1 and only encrypt traffic sourced from 131.108.200.0/24 destined for R1's Ethernet network, 131.108.100.0/24. 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 131.108.255.1 255.255.255.252
 crypto map anyname1                                                       
!
Hostname R2
!
interface Serial0/0
 ip address 131.108.255.2 255.255.255.252
 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   131.108.255.1 set    HMAC_MD5+DES_56_CB       5       5     

R1 has an IPSec peer connection to R2, through the Serial0/0 interface (131.108.255.1). 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 = 131.108.255.2
 Extended IP access list 100
access-list 100 permit ip 131.108.100.0 0.0.0.255 131.108.200.0 0.0.0.255  
 Current peer: 131.108.255.2
 Security association lifetime: 4608000 kilobytes/180 seconds
 PFS (Y/N): N
 Transform sets={ anyname, }
 Interfaces using crypto map anyname1:
 Serial0/0                                                                 

Example 4-16 displays the fact that the crypto map named "anyname1" is peered to a remote router, 131.108.255.2, 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:

• http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fsecur_c/fipsenc/index.htm

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