IPSec VPN Design [Electronic resources] نسخه متنی

Key Management and Security Associations

You learned that there are two types of encryption algorithmssymmetric and asymmetric. You also know that IPSec VPNs are typically deployed across a public infrastructure because IPSec offers encryption services to keep the data confidential from non-intended recipients of the data. DES and 3DES are two of the most popular encryption algorithms used for IPSec VPNs; both are symmetric algorithms and, therefore, have to deal with the challenge of secure key distribution. Problems arise when the key distribution must be done over a public infrastructure such as the Internet.

Collectively, the generation, distribution, and storage of keys is called key management. All crypto systems must deal with key management issues. The default IPSec method for secure key negotiation is the Internet Key Exchange (IKE) protocol. IKE is designed to provide mutual authentication of systems, as well as to establish a shared secret key to create IPSec security associations. Before delving into how IKE works, it may be helpful to review the Diffie-Hellman key management protocol that is used by IKE to exchange a secret key over an insecure medium (such as the Internet).

The Diffie-Hellman Key Exchange

Whitfield Diffie and Martin Hellman first published their algorithm in 1976. This algorithm is based on the difficulty of solving the discrete logarithm problem. In short, the situation is as follows (using the classic cryptographic characters of Alice, Bob, and Eve):

Alice wishes to communicate with Bob securely.

In order to achieve this secure communication, Alice needs to establish a session key with Bob, but they have to somehow agree on a shared key over a public medium that is insecure.

To make matters worse, Eve wishes to monitor this communication.

In this section, you'll see how the Diffie-Hellman key exchange can help this situation. The algorithm has two system parameters, p and g. The parameters are both public and, therefore, may be used by all the users in a system. Parameter p is a large prime number and parameter g (usually called a generator) is an integer less than p, which is capable of generating every element from 1 to p1 when multiplied by itself a certain number of times modulo the prime p.

First, Alice generates the random private value a and Bob generates the random private value b. Then they derive their public values using parameters p and g and their private values. Alice's public value is X=g^a mod p and Bob's public value is Y=g^b mod p. They then exchange their public values. Finally, Alice computes k_ab=(g^b)^a mod p, and Bob computes k_ba=(g^a)^b mod p. Because k_ab=k_ba=k, Alice and Bob now have a shared secret key k. The protocol depends on the discrete logarithm problem for its security. It assumes that it is computationally infeasible to calculate the shared secret key k=g^ab mod p given the two public values g^a mod p and g^b mod p when the prime p is sufficiently large. Although all of this has been accomplished with Eve monitoring, she cannot determine the value of the shared key. Figure 2-11 illustrates a graphical representation of the Diffie-Hellman key exchange.

Note

The possibility of a "man-in-the-middle" attack remains a serious security problem for public keybased algorithms. Suppose Alice wishes to communicate with Bob and Eve wishes to eavesdrop on the conversation or possibly deliver a false message to Bob. To get communications started, Alice must ask Bob for his public key. If Bob sends his public key to Alice and Eve is able to intercept it, a man-in-the-middle attack can begin. In order to perpetrate the attack, Eve sends Alice a public key for which she has the private, matching, key. Believing this public key to be Bob's, Alice encrypts her message with Eve's key and sends the encyphered message back to Bob. Eve again intercepts and decyphers the message, keeps a copy, and reencyphers it (after alteration, if desired) using the public key Bob originally sent to Alice. When Bob receives the newly encyphered message, he will believe it came from Alice. Strong authentication is required between the peers to mitigate these types of attacks.

Security Associations and IKE Operation

A security association, more commonly referred to as an SA, is a basic building block of IPSec. An SA is an entry in the SA database (SADB), which contains information about the security that has been negotiated between two parties for IKE or IPSec. There are two types of SAs:

IKE or ISAKMP SA

IPSec SA

Although it is common practice to use the term SA to encompass both types, it is important to make the distinction for troubleshooting purposes, because each type of SA achieves a different purpose. Both SA types are established between IPSec peers using the IKE protocol.

IKE SAs between peers are used for control traffic, such as negotiating algorithms to use to encrypt IKE traffic and authenticate peers. There is only one IKE SA between peers, and it usually has less traffic and a longer lifetime than IPSec SAs.

IPSec SAs are used for negotiating encryption algorithms to apply for IP traffic between the peers, based on policy definitions that define the type of traffic to be protected. Because they are unidirectional, at least two IPSec SAs are needed (one for inbound traffic and the other for outbound traffic). It is possible to have multiple pairs of IPSec SAs between peers to describe unique disjoint sets of IP hosts or IP data traffic. IPSec SAs also usually have more traffic and a shorter lifetime than IKE SAs.

The establishment and maintenance of both ISAKMP/IKE SAs and IPSec SAs is a major function of the IKE protocol. The number of RFCs in the IETF IPSec working group related to key exchange and negotiation can be intimidating and confusing, as it is spread over four RFC documents: IKE (RFC 2409), ISAKMP (RFC 2408), OAKLEY (RFC 2412), and the ISAKMP Domain of Interpretation (RFC 2407). The relationships between these standards are not clearly defined in the documents themselves. This chapter attempts to clarify this quagmire of terminology and its related concepts.

IKE operates in two phases to establish these IKE and IPSec SAs:

Phase 1 provides mutual authentication of the IKE peers and establishment of the session key. This phase creates an ISAKMP SA (a security association for IKE, sometimes referred to as an IKE SA) using a DH exchange, cookies, and an ID exchange. Once an ISAKMP SA is established, all IKE communication between the initiator and responder is protected with encryption and an integrity check that is authenticated. The purpose of IKE phase 1 is to facilitate a secure channel between the peers so that phase 2 negotiations can occur securely.

Phase 2 provides for the negotiation and establishment of the IPSec SAs using ESP or AH to protect IP data traffic.

Note

Even though we use ISAKMP and IKE interchangeably, they are different. ISAKMP defines how IPSec peers communicate, the constructs of the message exchange between the peers, and the state transitions they go through to establish their connection. ISAKMP provides the means to authenticate a peer and to exchange information for key exchange. However, ISAKMP does not define how an authenticated key exchange is done; IKE defines how the key exchange is done.

Before we delve into IKE phase 1 and phase 2 operations, we will quickly review the ISAKMP header, which is shown in Figure 2-12.

IKE messages are constructed by chaining ISAKMP payloads to an ISAKMP header. The initiator and responder cookies in the header are created by each peer and are used in conjunction with the message ID to determine the state of an in-progress ISAKMP exchange. The cookies are eight bytes of random values that are used to identify the IKE SA. The cookies are formed by a hash of the peer identity (IP address, port, and protocol), a locally generated secret number, the date, and the time. The cookies serve as a sort of ISAKMP SPI.

The Next payload field indicates that the ISAKMP payload immediately follows the header. ISAKMP versions are identified by Major and Minor fields. So far, the Major version is only 1, and the Minor version is zero. The exchange type shows the type of message being used. The flags are one octet in length. There are only three bits that are used, starting with the least significant bit. Bit 0 is the encryption bit. When set to 1, it means the payload is encrypted. Bit 1 is the commit bit and, if set, it ensures that encrypted material is not received prior to SA establishment. Bit 2 is the authentication bit and implies, if set, that the payload will be only authenticated and not encrypted. The length field, which is four octets in length, indicates the length of the total message, which is the header plus the payloads. Refer to RFC 2408 for more information on the header.

IKE Phase 1 Operation

IKE phase 1 offers two modesMain and Aggressive. The result of each mode is the establishment of an ISAKMP/IKE SA. The IKE SA has various parameters that are negotiated between two peers. The mandatory parameters are the encryption algorithm, hash algorithm, authentication method, Diffie-Hellman group, and optional parameters such as lifetime. Example 2-1 shows how to configure these IKE phase 1 parameters on a Cisco IOS router.

Example 2-1. Configuring IKE Phase 1 Parameters on a Cisco IOS Router

crypto isakmp policy 1
encryption 3des
hash md5
group2
lifetime
authentication pre-shared
Show cry isakmp policy

Bear in mind that the configuration in Example 2-1 shows only one set of possible parameters. Each parameter has a range of values, and there can be many possibilities for the encryption algorithm parameter. The base encryption algorithms that are supported by IKE are DES, 3DES, and AES. Other encryption algorithms, defined in the IKE RFC, can also be used. The hash algorithm used is always an HMAC version of the negotiated hash algorithm. The Diffie-Hellman group determines the parameters to use when the peers engage in DH exchange. The group number implicitly defines these parameters. The optional parameter lifetime, which determines the life of the IKE SA, can be configured in either seconds or kilobytes.

Note

It should be noted that you can configure multiple sets of IKE policy parameters (by changing the index number 1 in Example 2-1). The initiator can offer more than one IKE policy and the responder can match the offered policies against all of its policy sets.

The parameter with the most impact on the IKE exchange itself is the authentication method. There are four types of authentication methods available with IKE: pre-shared key, digital signature, public key encryption with four encryptions, and public key encryption with two encryptions. You will explore these methods further in this chapter.

Main Mode

Main Mode consists of six messagesthree in each directionexchanged between the initiator and responder. It offers identity protection and considerable flexibility in terms of the parameters and configurations that can be negotiated. Figure 2-13 illustrates the Main Mode operation.

In the first exchange, initiator sends an ISAKMP header with a cookie Ci (initiator cookie) and an SA payload (SAi). The SAi is used for communicating the various phase 1 parameters (encryption algorithm, hash algorithm, authentication method, lifetime, and so on). In the second exchange, the responder replies with selected parameters for each of the proposals along with the SA header response (SAr) and the ISAKMP header with a cookie Cr (responder cookie). The responder picks one of the offered proposals in its entirety and returns thatit is not allowed to pick and choose attributes from different proposals. If none of the proposals match, then the responder will return a notify payload rejecting the proposals. The third and fourth exchanges occur when the keying materials are exchanged.

Once the keying materials are exchanged, four different keys are derived. The value SKEYID (Shared Key ID) and the key resulting from the DH exchange, K, are used to derive three additional keys:

SKEYID_d= hashfunc(SKEYID, K|C_I|C_R|0)

SKEYID_a hashfunc(SKEYID, SKEYID_d|K|C_I|C_R|1)

SKEYID_e = hashfunc(SKEYID, SKEYID_a|K|C_I|C_R|2)

SKEYID is derived differently for each authentication where hashfunc(key, data) is the negotiated hash function using the key over the data mechanism. SKEYID_d is used to derive more keying material if such material is required and perfect forward secrecy (PFS) is not required. SKEYID_a is used as the key to provide data integrity for ISAKMP messages. SKEYID_e is used as the key for encryption of IKE messages.

The fifth and sixth messages are encrypted with SKEYID_e and authenticated using the hashes derived, HASH_i and HASH_r, along with the different phase 1 encryption and hash algorithm that was negotiated as part of the first two exchanges and use of SKEYID_e and SKEYID_a. The main part of the exchange is the identification of the initiator and responder IDi and IDr.

HASH_i = hash(SKEYID, X|Y|Ci|Cr|SAr|IDi)

HASH_r = hash(SKEYID, X|Y|Cr|Ci|SAi|IDr)

One point to note in Main Mode is that that because the ID payload is encrypted, the responder has no idea who he is talking to. Therefore, in the case of Main Mode using a pre-shared key, the identity can be based only on the source IP address of the initiating peer.

Aggressive Mode

IKE Aggressive Mode needs only three exchanges, unlike Main Mode's six exchanges, that perform key negotiation and authentication, speeding up the IKE transaction processing. The increase in speed comes at the cost of some security, however. Figure 2-14 shows Aggressive Mode negotiation.

In the first message, the initiator sends the ISAKMP header, security association, DH public value, nonce, and the identification ID (IDi). In the second message, the responder replies with all the chosen transforms for each of the proposals and DH half key. This message is authenticated but not encrypted.

The third message is sent by the initiator back to the responder with the message authenticated such that the responder can make sure that the hash matches the hash calculated, which would confirm that all is well. One of the primary uses of Aggressive Mode is for remote access IKE clients when the responder has no prior knowledge of the address of the initiator and pre-shared keys are used as the authentication method. Aggressive Mode is less secure than Main Mode because identities are passed in the clear and DH parameters cannot be negotiated.

Authentication Methods

As mentioned earlier, one of the parameters with the most impact on the IKE phase 1 exchange itself is the authentication method. Next, you'll look at the two widely deployed authentication methods: pre-shared key and digital signatures.

Pre-shared Key Authentication

In this method, both the initiator and responder must have the same pre-shared keys; otherwise, the IKE tunnel will not be built due to the pre-shared key mismatch. The keys are agreed upon typically using an out-of-band technique. In a previous section in this chapter, you reviewed the DH exchange and saw how SKEYIDs are generated. The other keys are generated from SKEYID. The value of SKEYID generated for pre-shared key is

SKEYID = hash (Pre-Shared Key, Ni|Nr)

One disadvantage of using pre-shared keys in IKE Main Mode is that, because the ID payloads are encrypted, the responder is not aware of the identity of the initiator. In remote access scenarios (such as telecommuting), the source IP address of the initiator is not known in advance to the responder. In such cases, Aggressive Mode is the only choice with pre-shared key authentication.

Due to its simplicity, this authentication method is widely deployed for mass IPSec VPN deployment. The Cisco IOS configuration for this method is shown in Example 2-2.

Example 2-2. Cisco IOS Configuration for Setting Pre-shared Keys

crypto isakmp policy 1
encryption 3des
hash md5
group2
lifetimez
authentication pre-shared
crypto isakmp key ciscovpn 9.1.1.35
crypto isakmp key wildvpn address 0.0.0.0 0.0.0.0

Digital Signature Authentication

In the case of digital signatures, peers can be authenticated with public key signatureseither DSS or RSA. Currently, Cisco IOS only supports RSA. Public keys are usually obtained using certificates. IKE allows for the exchange of certificates between the initiator and responder. Figure 2-15 shows an IKE exchange with a digital signature.

The important thing to point out in Figure 2-15 is that in the third and fourth message exchanges, a request for the certificate is sent by the initiator to the responder, and vice versa, along with a nonce (Ni,Nr) and the DH public values. In the fifth and sixth message exchanges, the certificates are actually exchanged. Although the use of certificate is optional, it has become a standard implementation, as shown below.

SIG_i= PRIVATEKEY_i(HASH_i)

SIG_r = PRIVATEKEY_r(HASH_r)

The key thing is the HASH_i and HASH_r are signed by the corresponding private keys to form the message digest SIG_i and SIG_r. Recipients of the signature will use the signer's public key to decrypt and verify the message. The public keys, along with proof of identity (ID), are in the certificates. The fifth and sixth message exchanges are encrypted using SKEYID_e; therefore, the certificate payload is also encrypted. The recipient must decrypt the packet and get the public key from the certificate before the signed hash is authenticated. The method for generating SKEYID is as follows:

SKEYID = hash(Ni|Nr|K)

We have already shown how the other keys are generated from SKEYID.

The creation and management of certificates using a Certificate Authority (CA) server is beyond the scope of the IPSec standard. One thing worth mentioning, however, is that certificates contain public keys signed by a trusted CA, which provides a third-party relationship trusted by both the authenticating peers. The Public Key Infrastructure (PKI) is a good example of a certificate management system. For more information on PKI, refer to the RFC material managed within the IETF PKIX group, or obtain a reference book on PKI.

IKE Phase 2 Operation

IKE phase 1 creates the IKE/ISAKMP SAs and phase 2 establishes the IPSec SA in each direction. Phase 2 is also referred to as Quick Mode. At the completion of Quick Mode, the two peers should be ready to pass traffic using ESP or AH modes. Because an IPSec SA is unidirectional, there will be a minimum of two IPSec SA between two IPSec peers. Figure 2-16 shows the Quick Mode exchange.

Quick Mode

Quick Mode has three exchanges. All of these messages are protected by IKE, which means that all of the packets are encrypted and authenticated by SKEYID_e and SKEYID_athe same keys derived in IKE phase 1.

The first message from the initiator has the ISAKMP header and the IPSec SA payload with all the proposals and transforms that will be used for bulk data. A new nonce (Ni2) will be exchanged between the initiator and responder. The new nonce is used to generate fresh key material and may also prevent replay attacks. All the IPSec keys are derived from SKEYID_d; therefore, an attacker with knowledge of SKEYID_d will be able to derive all the current and future keys in use for IPSec until IKE renegotiates. To improve the protection of IPSec keys, Perfect Forward Secrecy (PFS) is used to decouple the relation of future keys from existing keys. When PFS is enabled, new DH public values (X,Y) will be exchanged and the resulting shared secret K will be used to generate new key material as follows:

HASH(1) = hash (SKEYIDa, Mid|SAi|Ni2) without PFS

HASH(1) = hash (SKEYIDa, Mid|SAi|Ni2|X|IDi|IDr) with PFS

The Message ID (Mid) is important because there may be multiple Quick Mode transactions between two peers, and a unique identifier is needed to distinguish them. The Mid, which is part of the ISAKMP header, serves as this unique identifier.

The second message is sent from the responder to the initiator with the chosen proposal along with the ISAKMP header, nonce (Nr2), and HASH(2):

HASH(2) = hash (SKEYID_a, Mid|Sar|Ni2|Nr2) without PFS

HASH(2) = hash (SKEYIDa, Mid|SAr|Ni2|Nr2|Y|IDi|IDr)with PFS

In the third and final message, the initiator authenticates with HASH3. This is to validate the communication channel prior to passing IPSec traffic. If the third message is not validated, an attacker could use previous packets of a Quick Mode transaction and replay them, thereby consuming resources. The third message is as follows:

HASH(3) = hash(SKEYIDa, 0|Mid|Ni2|Nr2)

An important point to highlight is that following the second exchange, the initiator has enough information to derive key material and to actually start sending traffic. Once the initiator sends the third message, it may start sending IPSec traffic. If the responder has not received the third message, or if it is still authenticating the third message when the data packets start arriving, the packets will be dropped. To avoid this scenario, the responder sets the commit bit during the second message exchange, which states that the initiator must wait for the recipient's response. In the third exchange, the initiator acknowledges the commit requirement by setting the commit bit. Once the responder has authenticated the third message, it sends a fourth message back to the initiator stating that it is now ready for the IPSec traffic.

Note

Cisco IOS routers will respect commit bit if it is passed on from another vendor box, but will never initiate with commit bit.

At the completion of the third message exchange, the keying material can be generated for the data transfer:

KEYMAT = HASH(SKEYID_d, protocol, SPI|Ni2|Nr2) without PFS

The protocol assigned is ESP or AH and the SPI is the random number that forms part of the security protocol header. Alternatively, KEYMAT may be defined as:

KEYMAT = HASH(SKEYID_d, K|protocol, SPI|Ni2|Nr2) with PFS

Note that here, K is the new shared secret created between the two peers using a new DH key exchange.

At the start of this section, it was noted that there will be a minimum of two IPSec SAs created on each peeran inbound SA and an outbound SA. Both SAs will have their own KEYMAT, as the SPI will be different for the inbound and outbound direction; each peer chooses its outbound SPI, which is the other peer's inbound SPI. If we consider two peers, the inbound SPI assigned to each peer is created by itself in order to avoid collision of SPI values. That is, if the destination peer created the inbound SPI, the two peers could potentially create the same SPI values, and therefore inbound SAs/SPIs are created by the IPSec gateway, which creates them for all the peers that it talks to. The outbound SA/SPI of one peer is the inbound SA/SPI for the other peer.

IPSec Packet Processing

Processing of packets on a router or a host is typically an implementation issue. Interestingly, RFC 2401 describes a general model for implementation in support of interoperability and achieving the functional goals of IPSec. The model describes two databases that all IPSec implementations will implement:

Security Policy Database (SPD)

Security Association Database (SADB)

The SPD holds the policy definitions that determine the disposition of all IP trafficinbound or outboundbetween two IPSec peers. The SADB contains parameters that are associated with each (active) security association.

Security Policy Database

Security policies applied to inbound and outbound IP packets are stored in the database called Security Policy Database (SPD). The security policy database defines various selectors to identify packets that require IPSec services. The selectors are as follows:

Destination IP address

Source IP address

Name

Data sensitivity level

Transport Layer protocols

Source and destination ports

One or more of these selectors define the set of IP traffic encompassed by this policy entry where each policy is represented in the SPD. Each entry includes an indication of whether traffic matching this policy will be bypassed, discarded, or subject to IPSec processing. If IPSec processing is to be applied, the entry includes an SA (or SA bundle) specification that lists the IPSec protocols, modes, and algorithms to be employed.

Security Association Database (SADB)

Each entry in the SADB defines the parameters associated with one SA. When an IPSec SA is created, the SADB is updated with all the parameters associated with the Security Association (SA). The SA entry for an inbound IPSec packet is obtained by indexing into the SADB with the destination IP address in the outer IP header, SPI, and IPSec security protocol (ESP or AH). The SA entry for outbound IPSec packets is obtained by a pointer to the SADB in the SPD. The SADB contains the following nine parameters for IPSec processing:

Sequence number The 32-bit value provided in the ESP or AH header.

Sequence number overflow A flag that indicates that the sequence number value has gone beyond the 2^32 value and, hence, the SA must be deleted and a new SA negotiated between the IPSec peers.

Anti-replay window A 32- or 64-bit counter, used to determine if an inbound IPSec packet is a replayed packet.

SA lifetime Determined by a time-frame or byte count. The first lifetime to expire causes the SA to be deleted and a new one to be created. The SADB is responsible for management of an SA's lifetime. There are two lifetime triggersone is a soft lifetime and the other is hard lifetime. A soft lifetime determines the point in time prior to a hard lifetime expiration when a new IPSec SA should be initiated. This allows the creation of a new SA before the old SA's expiration of the hard lifetime, thereby preventing loss of data.

Modes Determines whether tunnel mode or transport mode is used.

AH authentication algorithm Determines the choice of MD5 or SHA authentication and defines the keys to create the authentication digest.

ESP authentication algorithm Determines the choice of MD5 or SHA authentication and defines the keys to create the authentication digest.

ESP encryption algorithm The algorithm used for encryption DES, 3DES, or AES and defines the keys and IV for encryption.

Path MTU Any observed PMTU and aging variables.

Example 2-3 shows the SADB in a Cisco router running IOS.

Example 2-3. Security Association Database (SADB)

vpn-gw1-east#show cry ipsec sa
interface: FastEthernet0/0
Crypto map tag: vpn, local addr. 9.1.1.35
local  ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.0.68.0/255.255.255.0/0/0)
current_peer: 9.1.1.146:500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 10, #pkts encrypt: 10, #pkts digest 10
#pkts decaps: 19, #pkts decrypt: 19, #pkts verify 19
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 9.1.1.35, remote crypto endpt.: 9.1.1.146
path mtu 1500, media mtu 1500
current outbound spi: A8992968
inbound esp sas:
spi: 0xDFCB9E37(3754663479)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 2000, flow_id: 1, crypto map: vpn
sa timing: remaining key lifetime (k/sec): (4607997/3368)
IV size: 8 bytes
replay detection support: Y
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xA8992968(2828609896)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 2001, flow_id: 2, crypto map: vpn
sa timing: remaining key lifetime (k/sec): (4607998/3368)
IV size: 8 bytes
replay detection support: Y
outbound ah sas:
outbound pcp sas:

Cisco IOS IPSec Packet Processing

Next, you step through the IPSec packet processing on a Cisco router. See Figure 2-17 for this example.

The configuration of the routers shown in Figure 2-17 is shown in Example 2-4 and Example 2-5.

Example 2-4. Spoke Configuration

SPOKE-1-EAST
hostname spoke-1-east
!
!
ip domain-name cisco.com
!
!
crypto isakmp policy 1
authentication pre-share
crypto isakmp key cisco address 9.1.1.35
!
!
crypto IPSec transform-set test esp-3des esp-sha-hmac
!
crypto map vpn 1 IPSec-isakmp
set peer 9.1.1.35
set transform-set test
match address 100
!
!
!
interface Serial0/0
ip address 9.1.1.146 255.255.255.252
crypto map vpn
!
interface Ethernet0/1
ip address 10.0.68.1 255.255.255.0
half-duplex
!
ip classless
ip route 0.0.0.0 0.0.0.0 9.1.1.145
!
!
access-list 100 permit ip 10.0.68.0 0.0.0.255 10.1.1.0 0.0.0.255
!
!
line con 0
line aux 0
line vty 0 4
login
!
!
end

Example 2-5. Hub Configuration

VPN-GW1-EAST
hostname vpn-gw1-east
!
!
ip cef
ip audit notify log
ip audit po max-events 100
!
crypto isakmp policy 1
authentication pre-share
crypto isakmp key cisco address 9.1.1.146
!
!
crypto IPSec transform-set test esp-3des esp-sha-hmac
!
crypto map vpn 1 IPSec-isakmp
description spoke-1-east
set peer 9.1.1.146
set transform-set test
match address 100
!
!
controller ISA 1/1
!
!
interface FastEthernet4/0
ip address 10.1.1.1 255.255.255.0
duplex full
no cdp enable
!
interface FastEthernet5/0
ip address 9.1.1.35 255.255.255.240
duplex full
no cdp enable
crypto map vpn
!
ip classless
ip route 0.0.0.0 0.0.0.0 9.1.1.33
!
!
access-list 100 permit ip 10.1.1.0 0.0.0.255 10.0.68.0 0.0.0.255
!
!
line con 0
line aux 0
line vty 0 4
login
!
!
end

In this example, we assume that a device (10.0.68.5) on the router SPOKE-1-EAST's LAN 10.0.68.0/24 wants to communicate with another device (10.1.1.5) on the LAN 10.1.1.0/24 on the VPN-GW1-EAST router. We'll also assume that the communication is in the direction of spoke to hub.

When an IP packet is destined from the spoke device to the hub site, the IP configuration on the device on the spoke LAN site delivers the IP packet to the SPOKE-1-EAST. The IP routing configuration on the spoke router determines that the IP packet is to be routed out of the interface serial0/0.

Before the packet is transmitted out of this interface, notice that there is a crypto-map configured on the serial0/0 interface. This means that this packet may need to be processed by IPSec on the router.

The next step is to consult the SPD to see if there is a policy match for this packet (Source:10.0.68.5, Destination: 10.1.1.5). The Access List 100, which was configured as a policy match under the crypto-map, matches all packets with a source in the range of 10.0.68.0/24 and a destination in the range of 10.1.1.0/24. Our packet matches this policy; therefore, the packet needs to be IPSec protected. If the access list does not match a packet, the packet will be sent in the clear without any further IPSec processing.

The following configuration shows the data sensitivity level needed if the packet needs to be secured per SPD:

crypto IPSec transform-set test esp-3des esp-sha-hmac

The configuration specifies the use of 3DES encryption with ESP and SHA-HMAC for data integrity and that tunnel mode will be used for encapsulating this packet. The command show crypto ipsec transform-set can be used to verify the configuration:

spoke-1-east#show cry ipsec transform-set
Transform set test: { esp-3des esp-sha-hmac  }
will negotiate = { Tunnel,  },

The next step is to see if an IKE or IPSec SA is already established to the IPSec peer. Assume this is the first packet to this destination; hence, there will be no SA existing in the SADB. All packets that match this policy can be queued or dropped until the IKE and IPSec SA are established. IOS IPSec drops all packets while waiting for IKE and IPSec SAs to be established.

IKE phase 1 negotiation is performed between the peers to establish the IKE/ISAKMP SA. The parameters used for phase 1 are defined in the following configuration:

crypto isakmp policy 1
authentication pre-share
crypto isakmp key s0n0f1ke1sc0m1ng address 9.1.1.35
!
spoke-1-east# show cry isakmp policy
Protection suite of priority 1
encryption algorithm:   DES - Data Encryption Standard
hash algorithm:         Secure Hash Standard
authentication method:  Pre-Shared Key
Diffie-Hellman group:   #1 (768 bit)
lifetime:               86400 seconds, no volume limit
Default protection suite
encryption algorithm:   DES - Data Encryption Standard
hash algorithm:         Secure Hash Standard
authentication method:  Rivest-Shamir-Adleman Signature
Diffie-Hellman group:   #1 (768 bit)
lifetime:               86400 seconds, no volume limit

After the IKE and IPSec SA are established as shown in the following configuration, the original IP packet is encapsulated in IPSec tunnel mode using an ESP header. Recall that in tunnel mode, a new IP header is added. In this case, the source IP address of 9.1.1.150 and destination IP address of 9.1.1.35 are used in the IPSec encapsulating header. This packet is handed back to usual IP forwarding routines to process the packet.

spoke-1-east# show cry isakmp sa
dst             src             state           conn-id    slot
9.1.1.146        9.1.1.35       QM_IDLE               1       0
vpn-gw1-east# show cry eng conn act
ID Interface   IP-Address     State     Algorithm    Encrypt  Decrypt
1 FastEthernet0/0    9.1.1.146   set   HMAC_SHA+DES_56_CB  0        0
2000 FastEthernet0/0 9.1.1.146   set   HMAC_SHA+3DES_56_C  0       19
2001 FastEthernet0/0 9.1.1.146   set   HMAC_SHA+3DES_56_C  19       0

Next, the encrypted IPSec packet arrives into the hub router, and the presence of an IPSec header in the IP packet indicates that it must receive IPSec processing on the hub.

The outer header destination address (9.1.1.35), the security protocol ESP, and the SPI in the ESP header are used as indexes into the SADB to find the SA for this packet.

Once there is a hit in the SADB, the packet is authenticated and then decrypted using the proper transforms.

Once the packet is decrypted, the 5-tuple check of the policy corresponding to the packet is checked. The 5-tuple is the source address of the inner IP header, destination address of inner IP header, source port of inner header, destination port of inner header, and the IP protocol ID. Querying the SPD validates the 5-tuple. The lifetime counter in bytes is decremented and the anti-replay window is updated.

The packet would have been dropped in the following cases:

The SA was not in the SADB

The sequence number was on the left of the sliding window; therefore, the packet fails the replay check

Authentication fails

The length is incorrect

The SA lifetime has expired

If all goes well in the previous step, the packet is passed to usual IP packet processing on the hub router.

Note

Not only does IPSec require outgoing packets to be encrypted (if they match the proxy or access list), but also any incoming packets that match the reverse of the proxy or access list must be encrypted. If packets that match the reverse are received in clear text, they will be dropped.