
Cisco Secure VPN Exam Certification Guide - Cisco press
.pdf
58 Chapter 2: Overview of VPN and IPSec Technologies
Step 2 Establish an IPSec policy—The IPSec security and authentication capabilities are applied to certain traffic that passes between peers. You can choose to send all traffic between peers through the IPSec tunnel, but there is a significant performance penalty when using IPSec, so you should be selective in its application. However you choose to implement the IPSec tunnel, both ends of the tunnel must implement identical IPSec policies. Careful planning and documentation can simplify this process. You need the following information for your IPSec policy:
— IPSec protocol—AH or ESP
— Authentication—MD5 or SHA-1
— Encryption—DES or 3DES
— Transform or transform set—ah-sha-hmac esp-3des esp-md5-hmac or one of the other allowable combinations
— Identify traffic to be protected—Protocol, source, destination, and port
— SA establishment—Manual or IKE
Step 3 Examine the current configuration—Avoid issues with conflicting configuration parameters by checking existing IPSec settings on your device.
Step 4 Test the network before IPSec—Can you ping the peers that are going to participate in IPSec with your device? If not, you must fix that before you go any further.
Step 5 Permit IPSec ports and protocols—If you have enabled ACLs on any
|
devices along the path of the proposed IPSec VPN, be sure that those devices |
|
permit IPSec traffic. You must ensure that the following are permitted |
|
through the network: |
|
— UDP port 500—ISAKMP, identified by the keyword isakmp |
|
— Protocol 50—ESP, identified by the keyword esp |
|
— Protocol 51—AH, identified by the keyword ahp |
|
|
NOTE |
Protocols 50 and 51 are actual protocols within the TCP/IP stack. They are not ports used within |
|
a protocol, such as port 500 for ISAKMP within UDP. |
|
|
|
After you have ensured network connectivity, cleaned up your existing configuration, enabled |
|
IPSec traffic, and established your IKE and IPSec policies, you can begin the configuration |
|
process. Configuration processes for the Cisco VPN 3000 Series Concentrators are covered in |
|
detail throughout the remainder of this book. |

Establishing VPNs with IPSec 59
You can think of the IPSec process as the following five-step process:
Step 1 Interesting traffic initiates the setup of an IPSec tunnel.
Step 2 IKE Phase 1 authenticates peers and establishes a secure tunnel for IPSec negotiation.
Step 3 IKE Phase 2 completes the IPSec negotiations and establishes the IPSec tunnel.
Step 4 Once the tunnel has been established, secured VPN communications occur.
Step 5 When there is no more traffic to use IPSec, the tunnel is torn down, either explicitly or through timeout of the SA lifetimes.
The following sections examine these five processes in more detail.
Step 1: Interesting Traffic Triggers IPSec Process
As previously stated, you have absolute control over the traffic that gets processed by IPSec. You might want certain traffic between peers authenticated only, for example, for mail or intranet traffic. You might want to encrypt client/server traffic that interacts with your financial server. Maybe you want to encrypt everything going from peer A to peer B.
Whatever your security policy dictates is mirrored in access lists. Peers must contain the same access lists, and you can have multiple access lists for different purposes between peers. These ACLs are called crypto ACLs because of their application. They are simply extended IP access lists, but they work slightly differently because the permit and deny keywords have a different purpose for crypto ACLs. Figure 2-12 shows the effect of permit and deny statements on source and destination peers.
The permit and deny keywords have different functions on the source and destination devices. The following list describes those functions:
•permit at the source peer—Passes the traffic to IPSec for authentication, encryption, or both. IPSec modifies the packet by inserting an AH or ESP header and possibly encrypting some of or all of the original packet and then places it on the wire to the destination.
•deny at the source peer—Bypasses IPSec and puts the clear-text packet on the wire to the destination.
•permit at the destination peer—Passes the traffic to IPSec for authentication, decryption, or both. The ACL uses the information in the header to make its decision. In ACL logic, if the header contains the correct source, destination, and protocol, the packet must have been processed by IPSec at the sender and must now be processed by IPSec at the receiver.
•deny at the destination peer—Bypasses IPSec and assumes that the traffic has been sent in the clear.

60 Chapter 2: Overview of VPN and IPSec Technologies
Figure 2-12 Crypto ACLs
Clear-Text |
Packet |
Source |
Peer |
Crypto |
ACL |
deny |
permit |
IPSec |
Destination |
Clear-Text |
Peer |
Packet |
IPSec |
|
permit |
deny |
|
|
|
AH or ESP |
|
Packets |
Crypto |
|
ACL |
|
AH or ESP |
|
AH, ESP, or |
Packets |
|
Clear-Text |
|
|
Packets |
|
||
|
|
|
When these permit and deny keywords are used in the proper combinations, data are successfully protected and transferred. When they are not used in the proper combinations, data are discarded. Table 2-10 shows the various permit and deny keyword combinations and the actions that result from the combinations.
Table 2-10 Crypto ACL Actions
Source |
Destination |
Action |
|
|
|
permit |
permit |
Packet processed correctly |
|
|
|
permit |
deny |
Packet misunderstood and dropped |
|
|
|
deny |
permit |
Packet misunderstood and dropped |
|
|
|
deny |
deny |
Packet processed correctly |
|
|
|
You can readily see why it is so important for crypto ACLs to match on both ends of the IPSec VPN. Remember that Cisco ACLs always have an implicit deny all as the last entry. If your permit statements do not match on both ends, the destination is not able to process the packet information and the packet is discarded.

Establishing VPNs with IPSec 61
NOTE |
Remember that IPSec is an IP-only function. All your crypto ACLs must be extended IP ACLs, |
|
permitting you to identify source, destination, and protocol. |
|
|
Step 2: Authenticate Peers and Establish IKE SAs
IKE Phase 1 uses two different mode types to authenticate IPSec peers and establish an IKE SA policy between peers. These two modes are the Main mode and the Aggressive mode.
Main mode protects the identity of both peers during key exchange. This is the mode that is used by default on Cisco VPN products. When using Main mode, IKE performs three bidirectional exchanges between peers. Those three exchanges are as follows:
•
•
•
Algorithms and hashes are agreed upon.
Diffie-Hellman exchange is made, producing matching shared secret keys.
Verification of the other peer’s identity is made.
Only three messages are exchanged during Aggressive mode. More information is packed into the first message, providing key information to eavesdroppers that might be watching the traffic before the connection has been secured. Cisco products answer in Aggressive mode to products that initiate IKE Phase 1 in Aggressive mode, but their preference is for Main mode operation. Whether using Main mode or Aggressive mode, the end result of IKE Phase 1 is a secure tunnel between peers that protects the ISAKMP exchanges of IKE Phase 2 as the IPSec SA is negotiated.
Step 3: Establish IPSec SAs
IKE Phase 2 has one mode of operation, Quick mode, which begins immediately after the secured tunnel is established in IKE Phase 1. The following tasks are accomplished during IKE Phase 2:
1IPSec SA parameters are negotiated and agreed on by both peers within the protection of the IKE SA established in Phase 1.
2IPSec SAs are established.
3IPSec SAs are renegotiated periodically as needed.
4IPSec SAs an optionally perform an additional Diffie-Hellman key exchange.
Step 4: Allow Secured Communications
Once the IPSec SAs have been established in Step 3, secured traffic can be exchanged over the connection. IP packets across this IPSec tunnel are authenticated and/or encrypted, depending on the transform set selected. Figure 2-13 shows the use of a secure IPSec tunnel between peers.

62 Chapter 2: Overview of VPN and IPSec Technologies
Figure 2-13 IPSec Secure Tunnel
Peer A |
Peer B |
Router |
Router |
A |
B |
|
IPSec Tunnel |
Step 5: Terminate VPN
In normal operation, IPSec VPN tunnels can be terminated when one of the peers goes away, as might be the case in remote access VPNs when the mobile user packs up his system for the day. More frequently, however, they out based on the negotiated SA lifetimes in the IPSec SA and the IKE SA. When the SA terminates, keys are discarded.
When an IPSec SA times out and IPSec traffic still exists, the peers immediately go into IKE Phase 2 negotiations and reestablish the IKE SA using new keys. If the IKE SA times out, the peers must start with IKE Phase 1 negotiations to establish new IKE SAs and then renegotiate IPSec SAs.

Table of Protocols Used with IPSec 63
Foundation Summary
The Foundation Summary is a collection of tables, figures, and best practices that provide a convenient review of many key concepts in this chapter. For those who are already comfortable with the topics in this chapter, this summary could help you recall a few details. For those who just read this chapter, this review should help solidify some key facts. For anyone doing final preparation before the exam, these tables and figures are a convenient way to review the day before the exam.
Table of Protocols Used with IPSec
IPSec was designed to be able to use existing protocols and multipurpose protocols. The only two that are considered strictly IPSec protocols are Authentication Header and Encapsulating Security Payload. Table 2-11 outlines the protocols discussed in this chapter.
Table 2-11 Protocols Used with IPSec
Process |
Protocol |
Description |
|
|
|
IP Security (IPSec) |
Authentication Header |
A security protocol that provides data |
Protocol |
(AH) |
authentication and optional antireplay services. AH |
|
|
is embedded in the data to be protected (a full IP |
|
|
datagram). |
|
|
|
|
Encapsulating Security |
Security protocol that provides data privacy |
|
Payload (ESP) |
services, optional data authentication, and |
|
|
antireplay services. ESP encapsulates the data to be |
|
|
protected. |
|
|
|
Message encryption |
Data Encryption Standard |
Standard cryptographic algorithm developed by the |
|
(DES) |
U.S. National Bureau of Standards using 56-bit |
|
|
key. |
|
|
|
|
Triple DES (3DES) |
Standard cryptographic algorithm based on DES, |
|
|
using 168-bit key. |
|
|
|
Message integrity |
Hash-based Message |
A mechanism for message authentication using |
(hash) functions |
Authentication Code |
cryptographic hash functions. HMAC can be used |
|
(HMAC) |
with any iterative cryptographic hash function, for |
|
|
example, MD5 or SHA-1, in combination with a |
|
|
secret shared key. The cryptographic strength of |
|
|
HMAC depends on the properties of the underlying |
|
|
hash function. |
|
|
|
continues

64 Chapter 2: Overview of VPN and IPSec Technologies
Table 2-11 Protocols Used with IPSec (Continued)
Process |
Protocol |
Description |
|
|
|
Message integrity |
Message Digest 5 (MD5) |
A one-way hashing algorithm that produces a 128- |
(hash) functions |
|
bit hash. Both MD5 and Secure Hash Algorithm |
(continued) |
|
(SHA) are variations on MD4 and are designed to |
|
|
strengthen the security of the MD4 hashing |
|
|
algorithm. Cisco uses hashes for authentication |
|
|
within the IPSec framework. |
|
|
|
|
Secure Hash Algorithm-1 |
Algorithm that takes a message of less than 264 bits |
|
(SHA-1) |
in length and produces a 160-bit message digest. |
|
|
The large message digest provides security against |
|
|
brute-force collision and inversion attacks. SHA-1 |
|
|
[NIS94c] is a revision to SHA that was published in |
|
|
1994. |
|
|
|
Peer authentication |
Preshared keys |
A shared secret key that must be communicated |
|
|
between peers through some manual process. |
|
|
|
|
RSA digital signatures |
Public-key cryptographic system that can be used |
|
|
for encryption and authentication. The digital |
|
|
signature is a value computed with the RSA |
|
|
algorithm and appended to a data object in such a |
|
|
way that any recipient of the data can use the |
|
|
signature to verify the data’s origin and integrity. |
|
|
|
|
RSA encrypted nonces |
Nonces are random numbers used in security |
|
|
protocols to prove recentness of messages, but they |
|
|
can also be used as symmetric session keys. |
|
|
|
Key management |
Diffie-Hellman (D-H) |
A public-key cryptography protocol that allows two |
|
|
parties to establish a shared secret over insecure |
|
|
communications channels. Diffie-Hellman is used |
|
|
within Internet Key Exchange (IKE) to establish |
|
|
session keys. Diffie-Hellman is a component of |
|
|
OAKLEY key exchange. Cisco IOS Software |
|
|
supports 768-bit and 1024-bit Diffie-Hellman |
|
|
groups. |
|
|
|
|
Certificate Authority (CA) |
Entity that issues digital certificates (especially |
|
|
X.509 certificates) and vouches for the binding |
|
|
between the data items in a certificate. |
|
|
|

Creating VPNs with IPSec 65
Table 2-11 Protocols Used with IPSec (Continued)
Process |
Protocol |
Description |
|
|
|
Security |
Internet Key Exchange |
IKE establishes a shared security policy and |
Association (SA) |
(IKE) |
authenticates keys for services (such as IPSec) that |
|
|
require keys. Before any IPSec traffic can be |
|
|
passed, each router/firewall/host must verify the |
|
|
identity of its peer. This can be done by manually |
|
|
entering preshared keys into both hosts or by a CA |
|
|
service. |
|
|
|
|
Internet Security |
Internet IPSec protocol [RFC 2408] that negotiates, |
|
Association and Key |
establishes, modifies, and deletes security |
|
Management Protocol |
associations. It also exchanges key generation and |
|
(ISAKMP) |
authentication data (independent of the details of |
|
|
any specific key generation technique), key |
|
|
establishment protocol, encryption algorithm, or |
|
|
authentication mechanism. |
|
|
|
IPSec Preconfiguration Processes
Most projects go much easier if you spend some careful planning time before you begin. The same is true for implementing IPSec security. Take the following steps before you begin the task of configuring IPSec on your Cisco devices:
Step 1 Establish an IKE policy.
Step 2 Establish an IPSec policy.
Step 3 Examine the current configuration.
Step 4 Test the network before IPSec.
Step 5 Permit IPSec ports and protocols.
Creating VPNs with IPSec
After you configure your Cisco devices for IPSec, the setup and termination of IPSec happens automatically. The following steps are involved in that process:
Step 1 Interesting traffic triggers IPSec process.
Step 2 Authenticate peers and establish IKE SAs (IKE Phase 1).
Step 3 Establish IPSec SAs (IKE Phase 2).
Step 4 Allow secured communications.
Step 5 Terminate VPN.

66 Chapter 2: Overview of VPN and IPSec Technologies
Chapter Glossary
The following terms were introduced in this chapter or have special significance to the topics within this chapter.
antireplay A security service where the receiver can reject old or duplicate packets to protect itself against replay attacks. IPSec provides this optional service by use of a sequence number combined with the use of data authentication.
Cisco Unified Client Framework A consistent connection, policy, and key management method across Cisco routers, security appliances, and VPN Clients.
data authentication Process of verifying that data have not been altered during transit (data integrity), or that the data came from the claimed originator (data origin authentication).
data confidentiality A security service where the protected data cannot be observed.
data flow A grouping of traffic, identified by a combination of source address/mask, destination address/mask, IP next protocol field, and source and destination ports, where the protocol and port fields can have the values of any. In effect, all traffic matching a specific combination of these values is logically grouped together into a data flow. A data flow can represent a single TCP connection between two hosts, or it can represent all the traffic between two subnets. IPSec protection is applied to data flows.
Elliptic Curve Cryptography (ECC) A public-key encryption technique based on elliptic curve theory that can be used to create faster, smaller, and more efficient cryptographic keys. ECC generates keys through the properties of the elliptic curve equation instead of using the traditional method of generation as the product of large prime numbers. The technology can be used in conjunction with most public-key encryption methods, such as RSA and Diffie-Hellman.
peer In the context of this document, a router, firewall, VPN concentrator, or other device that participates in IPSec.
Perfect Forward Secrecy (PFS) A cryptographic characteristic associated with a derived shared secret value. With PFS, if one key is compromised, previous and subsequent keys are not compromised, because subsequent keys are not derived from previous keys.
Scalable Encryption Processing (SEP) Cisco VPN 3000 Series Concentrator modules that enable users to easily add capacity and throughput.
Security Association (SA) An IPSec security association (SA) is a description of how two or more entities use security services in the context of a particular security protocol (AH or ESP) to communicate securely on behalf of a particular data flow. It includes things such as the transform and the shared secret keys to be used for protecting the traffic.

Chapter Glossary 67
Security Parameters Index (SPI) This is a number that, together with an IP address and security protocol, uniquely identifies a particular security association. When using IKE to establish the security associations, the SPI for each security association is a pseudo-randomly derived number. Without IKE, the SPI is manually specified for each security association.
transform A transform lists a security protocol (AH or ESP) with its corresponding algorithms. For example, one transform is the AH protocol with the HMAC-MD5 authentication algorithm; another transform is the ESP protocol with the 56-bit DES encryption algorithm and the HMAC-SHA authentication algorithm.
tunnel In the context of this document, a secure communication path between two peers, such as two routers. It does not refer to using IPSec in Tunnel mode.