|
New IP Header
|
IPSec Header
|
Original Header
|
IP Data (Not Encrypted)
Original IP Datagram
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
IP HDR
IP Data
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
IP Header (Port 50)
Security Parameter Index (SPI)
Sequence Number
Payload Data (variable)
PAD (0-255 bytes)
PAD Length
Next Header
IP Data
Authentication Data
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.
NOTE AH provides data origin authentication and optional replay-detection services. AH doesn't provide data confidentiality (or encryption). Authentication is done by applying a oneway hash to create a message digest of the packet. Replay detection can be implemented by using the sequence number in the AH packet header.
Figure 4-11 AH Header (Tunnel Mode)
AH Header
IP Header (Port 51)
AH Header
TCP/UDP Header
Payload
| | Fields protected by AH | | Unprotected (variable) Fields
|
Ver Le
|
ToS
|
Total Length
|
|
ID
|
Flags, Fragment
|
|
TTL
|
Protocol
|
Header Checksum
|
|
Source IP Address
|
|
Destination IP Address
|
|
|
|
Next Header
|
Payload Length
|
Reserved
|
Security Parameter Index (SPI)
Security Parameter Index (SPI)
Sequence Number
Authentication Data
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.
NOTE Cisco devices use main mode but can respond to peers using aggressive mode. Cisco IOS 12.2T and 12.3 now support configurable options as well.
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
IKE Phase 1 Summary
IKE Phase 1 Summary
Figure 4-12 IKE Phase I Summary
 - Remote peer
|
IKE SA Parameters DES MD5 Pre-share
DH2 Lifetime
|
IKE Phase 1
|
IKE SA Parameters DES MD5 Pre-share
DH2 Lifetime
|
|
Performs authenticated Diffie-Hellman exchange Provides protection of identities of IKE peers Finally data can be transferred
Negotiates IKE policy
Performs authenticated Diffie-Hellman exchange Provides protection of identities of IKE peers Finally data can be transferred
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.
NOTE Perfect forward secrecy can be requested as part of the IKE SA. PFS ensures that a given IPSec SA key was not derived from any other secret. In other words, if someone were to break a key or get the key used between two peers, PFS ensures that the attacker would not be able to derive any other key. If PFS was not enabled, someone could hypothetically break the IKE SA secret key, copy all the IPSec-protected data, and use knowledge of the IKE SA secret to compromise the IPSec SA's setup by this IKE SA. With PFS, breaking IKE would not give an attacker immediate access to IPSec. The attacker would have to break each IPSec SA individually.
Changing the secret key being used for encryption after some period of time (or after a specified number of bytes have been encrypted) is a good idea. Changing keys makes it more difficult for an attacker to derive the key or the newly created key.
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
IKE Phase 2 Summary
IPSec Tunnel
IKE Phase 2
Negotiates IPSec SA parameters protected by an existing IKE SA (during IKE phase 1) Establishes IPSec security associations, SA Periodically renegotiates IPSec SAs to ensure security Optionally performs an additional Diffie-Hellman exchange if PFS enabled
Figure 4-14 displays a typical IKE phase I/II completion. Figure 4-14 IKE Phase I/II
IKE Peers
IKE Protocol
IKE Peers
Host A
Host A
Transform, Transform, key material key material
IPSec Protocols ESP or AH
Host B
IPSec Tunnel
Host B
Steps Phase I/II
• Establish ISAKMP SA
• Negotiate ISAKMP SA policies such as encryption (MD5, 3DES, DSS)
• Exchange information needed to generate shared key
• Perform Diffie-Hellman calculation (shared secret)
• Generate the keys (pre-shared, DSS public keys)
• Communication can now begin by testing decryption
Table 4-5 summarizes the key components of IKE phases I and II. Table 4-5 IKE Phases I and II
|
Phase
|
Tasks
|
|
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.
NOTE Access control lists determine what traffic to encrypt. For example, you can specify that certain networks are to be encrypted and other networks are not. The permit statement encrypts data, and the deny statement (implicit) in an ACL does not send traffic encrypted. An ACL applied to IPSec configuration parameters does not stop IP routing on a Cisco IOS router.
Table 4-6 summarizes the key terms and concepts used in IPSec terminology.
Table 4-6 Summary of IPSec Terms and Concepts
|
Term
|
Meaning
|
|
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.
|
Table 4-6 Summary of IPSec Terms and Concepts (Continued)
|
Term
|
Meaning
|
|
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
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]
NOTE Crypto map entries created for IPSec pull together the various parts used to set up IPSec SAs, including the following:
■ Which traffic should be protected by IPSec (per a crypto ACL).
■ The granularity of the flow to be protected by a set of SAs.
■ Where IPSec-protected traffic should be sent (who the remote IPSec peer is).
■ The local address to be used for the IPSec traffic.
■ What IPSec security should be applied to this traffic.
■ Whether SAs are manually established or are established through IKE.
■ Other parameters that might be necessary to define an IPSec SA.
A dynamic crypto map entry is essentially a crypto map entry without all the parameters configured. It acts as a policy template where the missing parameters are later dynamically configured (as the result of an IPSec negotiation) to match a remote peer's requirements. This allows remote peers to exchange IPSec traffic with the router even if the router does not have a crypto map entry specifically configured to meet all the remote peer's requirements. Dynamic crypto maps are typically used to ensure security between a remote access IPSec client and Cisco IOS router, for example.
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
IKE Peers
Host A
Host A
131.108.100.1/24
access-list 100 permit ip 131.108.100.0 0.0.0.255 131.108.200.0 0.0.0.255
IIZC DcAtA^Al
Figure 4-16 Typical IPSec Topology Between Two Remote Routers
IIZC DcAtA^Al
IKE Peers 
131.108.200.1/24
- Mirrored ACLs -
-»•access-list 100 permit ip 131.108.200.0 0.0.0.255 131.108.100.0 0.0.0.255
131.108.200.1/24
- Mirrored ACLs -
-»•access-list 100 permit ip 131.108.200.0 0.0.0.255 131.108.100.0 0.0.0.255
The network administrator has decided to define the following ISAKMP parameters:
■ 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).
Preshared Keys Versus Manual Keys
The example shown here is an example of preshared keys whereby IKE is used to negotiate all SA parameters. You can also define IPSec not to use IKE, and this is referred to as manual IPSec or manual keys. Cisco strongly recommends that you use IKE with preshared keys or RSA signatures, because it is very difficult to ensure that all SA parameters are matching between remote peers. The Diffie-Hellman algorithm is a more secure method when generating secret keys between peers. Manual keys are vulnerable to intruders and unauthorized sources that gain entry to Cisco configuration files. Another major disadvantage of manual keys is that the IOS crypto map command used to establish SAs does not expire.
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
Example 4-13 R2 IKE and IPSec Configuration (Continued)
!IPSec configuration crypto map anynamel 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 anynamel
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 "anynamel" 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 "anynamel" 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.
NOTE IPSec can also be supported over the Cisco software tunnel interface. Typically, the tunnel (IP tunnel; GRE, for example) can be configured to carry non-IP traffic by defining a crypto map to the tunnel interface and a crypto control list.
Table 4-7 defines some key IPSec configuration show and debug commands available on Cisco IOS routers.
Readers' Questions
Table 4-7 IOS IPSec Configuration, Show, and Debug Commands
|
Command
|
Description
|
|
crypto map map-name seq-num ipsec-isakmp
[dynamic dynamic-map-name] [discover]
|
Creates a crypto map entry.
|
|
crypto ipsec transform-set transform-setname transforml [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.
|
NOTE A number of PC-based applications are available to the public that allow application layer encryptions.
An excellent e-mail encryption application is a product called Pretty Good Privacy (PGP). Designed and freely available on the Internet (http://www.pgp.com), PGP allows users to authenticate files and e-mail text, allowing only the intended recipient to decrypt the message. Users who send and receive encrypted data exchange keys. With encrypted data, the remote user's key is used to encrypt clear-text data or files. This ensures that the data is authenticated and not forged. Also check out http://www.gnupg.org for a free version of PGP.
Microsoft Outlook 2000 supports PGP and allows the client to encrypt and decrypt data using the preshared public keys.
Continue reading here: Extensible Authentication Protocol Protected EAP and Temporal Key Integrity Protocol
Was this article helpful?
|
|
