As you can see from the previous discussion, IPSec was designed to use a robust set of protocols and processes. You could establish VPNs without knowing much about these protocols, but the results would be haphazard at best. Good practice dictates a sequence of preparation steps that you should take before you can effectively configure a device for IPSec. Those preconfiguration steps are as follows:
Step 1 Establish an IKE policy—This policy must be identical on both ends of a VPN. The following elements go into the IKE policy:
— Key distribution method—Manual or certificate authority.
— Authentication method—Mostly determined by the key distribution method you select. Manual distribution uses preshared keys. Certificate authority distribution uses RSA encrypted nonces or RSA digital signatures.
— IP address and host names of peers—IP needs to know where to locate potential peers, and access control lists on intermediate devices need to permit the peers to communicate. IPSec configuration requires the fully qualified domain name (FQDN) of the device as well as the IP address.
— IKE policy parameters—Used by ISAKMP to establish the secure tunnel of IKE Phase 1. IKE policies consist of the following five parameters:
Encryption algorithm (DES/3DES) Hash algorithm (MD5/SHA-1)
Authentication method (Preshared, RSA encryption, RSA signatures) Key exchange (D-H Group 1/D-H Group 2)
IKE SA lifetime (86,400 seconds by default) 4 How IPSec works
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.
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.Figure 2-12 Crypto ACLs
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.
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.
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
Crypto
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:
1 IPSec SA parameters are negotiated and agreed on by both peers within the protection of the IKE SA established in Phase 1.
2 IPSec SAs are established.
3 IPSec SAs are renegotiated periodically as needed.
4 IPSec 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.
Figure 2-13 IPSec Secure 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.
IPSec Tunnel
Peer A Peer B
Router
A Router
B