example, Encapsulating Security Payload [ESP]). Under each proposal, the originator must delineate which algorithms are used in the proposal (for example, Data Encryption Standard [DES] with Message Digest 5 [MD5]). Rather than negotiate each algorithm individually, the algorithms are grouped into sets called IKE transform sets. A transform set describes which encryption algorithm, authentication algorithm, mode, and key length are proposed. These IKE proposals and transform sets are exchanged during the IKE main mode first exchange phase. If a transform set match is found between peers, main mode continues. If no match is found, the tunnel is torn down. In Figure , Router A sends IKE policies 10 and 20 to Router B. Router B compares Router B’s IKE policies, in our example policy 15, with those received from Router A. In this instance, there is a match: Router A’s policy 10 matches Router B’s policy 15. In a point-to-point application, each end may only need to have a single IKE policy defined. However, in a hub-and-spoke environment, the central site may require multiple IKE policies be defined to satisfy all the remote peers. DH Key Exchange
Diffie-Hellmann key exchange is a public key exchange method that provides a way for two peers to establish a shared secret key over an insecure communications path. There are several different Diffie-Hellmann algorithms, called groups, defined (Diffie-Hellmann Groups 1?7). A group number defines an algorithm and unique values. For example, Group 1 defines a modular exponentiation (MODP) algorithm with a 768-bit prime number. Group 2 defines a MODP algorithm with a 1024-bit prime number. During IKE Phase 1, the group is negotiated between peers. Between Cisco VPN devices, either Group 1 or Group 2 is supported. After the group negotiations are completed, the shared secret key is calculated. The shared secret key, SKEYID, is used in the derivation of three other keys: SKEYID_a, SKEYID_e, and SKEYID_d. Each key has a separate purpose. SKEYID_a is the keying material that is used during the authentication process, the SKEYID_e key is the keying material that is used in the encryption process, and the SKEY_d key is the keying material that is used to derive keys for non-Internet Security Association and Key Management Protocol (non-ISAKMP) SAs. All four keys are calculated during IKE Phase 1. In the example shown in Figure , User A and User B each establishes a private key. From the private key, the users calculate their public keys that they exchange. From each of their own private keys and the public key of the other peer, the users calculate a shared secret key that is used for encryption and decryption. Authenticate Peer Identity
When conducting business over the Internet, the device on the other end of a VPN tunnel must be authenticated before the communications path is considered secure. The last exchange of IKE Phase 1 authenticates the remote peer. There are three methods for identifying data origin:
Content 3.3 Implementing Site-to-Site IPsec VPN Operations 3.3.3 Step 3: IKE Phase 2 The purpose of IKE Phase 2 is to negotiate the IPsec security parameters that will be used to secure the IPsec tunnel. IKE Phase 2 performs these functions: IKE Phase 2 has one mode called quick mode. Quick mode occurs after IKE has established the secure tunnel in Phase 1. Quick mode negotiates a shared IPsec transform, derives shared secret keying material used for the IPsec security algorithms, and establishes IPsec SAs. Quick mode exchanges nonces that are used to generate new shared secret key material and to prevent replay attacks that can occur by generating bogus SAs. Quick mode is also used to renegotiate a new IPsec SA when the IPsec SA lifetime expires. Quick mode is used to refresh the keying material that is used to create the shared secret key based on the keying material derived from the Diffie-Hellmann exchange in Phase 1. IPsec Transform Sets
The ultimate goal of IKE Phase 2 is to establish a secure IPsec session between endpoints. Before the session can be established, each pair of endpoints negotiates the level of security that is required (for example, encryption and authentication algorithms for the session). Rather than negotiate each protocol individually, the protocols are grouped into an IPsec transform set. IPsec transform sets are exchanged between peers during quick mode. If a match is found between sets, IPsec session establishment continues. If no match is found, the session is torn down. In the example shown in Figure , Router A sends IPsec transform set 30 and 40 to Router B. Router B compares Router B’s set, transform set 55, with the sets received from Router A. In this instance, there is a match; Router A transform set 30 matches Router B transform set 55. These encryption and authentication algorithms form an SA. The transform set 40 on router A is not used. Security Associations
When two peers agree on which security services they will use, each VPN peer device enters the information in a Security Policy Database (SPD). The information in the SPD includes the encryption and authentication algorithm, destination IP address, transport mode, key lifetime, and any other security information. This information is referred to as the SA. An SA is a one-way logical connection that provides security to all traffic that is traversing the connection. Because most traffic is bidirectional, two SAs are required: one for inbound traffic and one for outbound traffic. The VPN device indexes the SA with a number called a Security Parameter Index (SPI). Rather than send the individual parameters of the SA across the tunnel, the source gateway, or host, inserts the SPI into the ESP header. When the IPsec peer receives the packet, the peer looks up the destination IP address, IPsec protocol, and SPI in the peer’s security association database (SAD) and then processes the packet according to the algorithms listed under the SPD. The IPsec SA is a compilation of the SAD and SPD. SAD is used to identify the SA destination IP address, IPsec protocol, and SPI number. The SPD defines the security services that are applied to the SA, encryption and authentication algorithms, and mode and key lifetime. The example in Figure shows a corporate-to-bank connection. In this connection, the security policy provides a very secure tunnel using 3DES, SHA-1, tunnel mode, and a key lifetime of 28,800. The SAD value is 192.168.2.1, ESP, and SPI-12. For the remote user who is accessing e-mail, a less secure policy is negotiated using DES, MD5, tunnel mode, and a key lifetime of 28,800. The SAD values for this user are a destination IP address of 192.168.12.1, ESP, and SPI-39. SA Lifetime
To maintain adequate security, change the SA and keys periodically. There are two parameters of an SA lifetime: type and duration. The first parameter is lifetime type. The second parameter is the unit of measure: either kilobytes of data or seconds of time. For example, a lifetime could be based on 10,000 kilobytes of data transmitted or 28,800 seconds of time expired. The keys and SAs remain active until the configured lifetime expires or until some external event, such as the client dropping the tunnel, causes them to be deleted.
Content 3.3 Implementing Site-to-Site IPsec VPN Operations 3.3.4 IPsec Tunnel Operation The last two steps in IPsec involve transferring