Chapter 1, “Introduction to VPNs,” introduced VPN concepts at a high level and presented an overview of several technologies that use VPNs. In this chapter, you will explore the building blocks of an IPSec VPN and obtain an understanding of IPSec architecture and how the various components of IPSec interact with each other to create a VPN. You will also look at some Cisco-specific IPSec implementation details and how IPSec packet processing is performed on Cisco IOS platforms.
A common misconception about IPSec is that it is a single protocol for providing these security services for IP traffic. In fact, IPSec is really a suite, or collection, of protocols for security defined by the IPSec working group in the IETF. The baseline IPSec architecture and fundamental components of IPSec are defined in RFC2401 as the following:
Security protocols—. Authentication header (AH) and encapsulation security payload (ESP)
Key management—. ISAKMP, IKE, SKEME
Algorithms—. for encryption and authentication
The interaction between these components of IPSec is intertwined in such a way that it is a bit hard to understand one of the components without understanding another. A quote from a draft submitted to the IPSec IETF working group sums it up pretty well: “Perhaps IPSec is well understood by some, but frequent questions on the developers’ mailing list confirm that one cannot become an IPSec expert merely by reading the RFCs. Much valuable information is buried deep in the list archives or in the minds of its designers.”
You will start your IPSec journey with an introduction to encryption terminology, followed by an examination of the IPSec security protocols (AH and ESP), and lastly, an explanation of security associations and key management.
Security and data confidentiality are prime requirements for any VPN. One of the primary reasons for choosing IPSec as your VPN technology is the confidentiality of data provided by the encryption that is built in.
Note
Encryption is the transformation of plain text into a form that makes the original text incomprehensible to an unauthorized recipient that does not hold a matching key to decode or decrypt the encrypted message.
Decryption is the reverse of encryption; it is the transformation of encrypted data back into plain text. Encryption techniques are as old as history—in fact, Julius Cæsar apparently did not trust his messengers and therefore encrypted his military messages to his generals with a simple encryption scheme; he replaced every A by D, every B by E, and so on. Only someone who knew the key (to shift each alphabetical letter by three, in this case) would be able to decrypt the message.
A cryptographic algorithm, also called a cipher, is the mathematical function used for encryption and decryption. Generally, there are two related functions—one for encryption and the other for decryption. Security of data in modern cryptographic algorithms is based on the key (or keys). It doesn’t matter if an eavesdropper knows your algorithm; if he or she doesn’t know your particular key, an eavesdropper will be unable read your messages.
Cryptographic algorithms can be classified into two categories:
Symmetric
Asymmetric
Symmetric cryptographic algorithms are based on the sender and receiver of the message knowing and using the same secret key. The sender uses a secret key to encrypt the message, and the receiver uses the same key to decrypt it. The main problem with using the symmetric key approach is finding a way to distribute the key without anyone else finding it out. Anyone who overhears or intercepts the key in transit can later read and modify messages encrypted or authenticated using that key, and can forge new messages. DES, 3DES, and AES are popular symmetric encryption algorithms. A detailed explanation of these algorithms is beyond the scope of this book.
Asymmetrical encryption algorithms, also known as public key algorithms, use separate keys—one for encryption and another for decryption. The encryption key is called the public key and can be made public. Only the private key, used for decryption, needs to be kept secret. Although the public and private keys are mathematically related, it is not feasible to derive one from the other. Anyone with a recipient’s public key can encrypt a message, but the message can only be decrypted with a private key that only the recipient knows. Therefore, a secure communication channel to transmit the secret key is no longer required as in the case of symmetric algorithms.
Figure 2-1 illustrates how public key encryption algorithms work. Bob and Alice communicate securely using public key encryption as follows:
Alice and Bob agree on a public key algorithm.
Bob sends Alice his public key and Alice sends Bob her public key.
Alice sends Bob a message, encrypting the message using Bob’s public key.
Bob receives the message and decrypts Alice’s message using his private key.
Note
Whenever an encryption theory or algorithm is used to describe a transaction between two parties, longstanding tradition has it that the parties are called Alice and Bob, and the eavesdropper in the middle is called Eve or Blackhat. Rumor has it that early on, the FBI and CIA actually went looking for Alice and Bob, because they were passing so many encrypted messages.
In reality, public key encryption is rarely used to encrypt messages because it is much slower than symmetric encryption; however, public key encryption is used to solve the problem of key distribution for symmetric key algorithms, which is, in turn used to encrypt actual messages. Therefore, public key encryption is not meant to replace symmetric encryption, but can supplement it and make it more secure.
Another good use of public key encryption is for message authentication, also known as a digital signature.
Encrypting a message with a private key creates a digital signature, which is an electronic means of authentication and provides non-repudiation. Non-repudiation means that the sender will not be able to deny that he or she sent the message. That is, a digital signature attests not only to the contents of a message, but also to the identity of the sender. Because it is usually inefficient to encrypt an actual message for authentication, a document hash known as a message digest is used. The basic idea behind a message digest is to take a variable length message and convert it into a fixed length compressed output called the message digest. Because the original message cannot be reconstructed from the message digest, the hash is labeled “one-way.” Alice and Bob’s communication using digital signature is shown in Figure 2-2.
Alice computes a one-way hash of a document that she wishes to send Bob.
Alice encrypts the hash with her private key. The encrypted message digest becomes the digital signature.
Alice sends the document along with the digital signature to Bob.
Bob decrypts the digital signature using Alice’s public key and also computes a one-way hash of the document received from Alice. If the two values match, Bob can be sure that the document came from Alice and the document was not tampered with in transit. The slightest change in the document will cause the values to not match and will cause the authentication to fail.
The objective of IPSec is to provide security services for IP packets at the network layer. These services include access control, data integrity, authentication, protection against replay, and data confidentiality.
Encapsulating security payload (ESP) and authentication header (AH) are the two IPSec security protocols used to provide this security for an IP datagram. Before looking into the IPSec security protocols, you must understand the two IPSec modes, transport and tunnel mode, and what services each provides.
In transport mode, an IPSec header (AH or ESP) is inserted between the IP header and the upper layer protocol header. Figure 2-3 shows an IP packet protected by IPSec in transport mode.
In this mode, the IP header is the same as that of the original IP packet except for the IP protocol field, which is changed to ESP (50) or AH (51), and the IP header checksum, which is recalculated. IPSec assumes the IP endpoints are reachable. In this mode, the destination IP address in the IP header is not changed by the source IPSec endpoint; therefore, this mode can only be used to protect packets in scenarios in which the IP endpoints and the IPSec endpoints are the same.
From an IPSec VPN point of view, this mode is most useful when traffic between two hosts must be protected, rather than when traffic moves from site-to-site, and each site has many hosts. The biggest challenge when using IPSec transport mode in the site-to-site model is the complexity involved in managing IPSec protection from any given host to all the possible peer hosts. Additionally, the two hosts’ IP addresses must be routable across the entire IP routing path. Due to the complexities of building an IPSec transport mode VPN from host to host, the typical VPN will use a VPN gateway to protect all the hosts from one site to all the hosts at a peer site. A typical IPSec VPN deployment occurs between sites where each site has multiple hosts behind a VPN gateway and the IPSec tunnel endpoints serve as the VPN gateway routers. With the VPN gateway protecting a set of host IP addresses, the IPSec transport mode has limited utility. IPSec transport mode can still be used for VPN connectivity if Generic Route Encapsulation (GRE) IP tunnels are used between the VPN gateways. The GRE tunnel endpoints serve as “host” endpoints. IPSec protects the GRE tunnel traffic in transport mode. Chapter 3, “Enhanced IPSec Features,” explores more about GRE and IPSec.
Note
Another limitation of transport mode is that it cannot be used with NAT translation of packets between IPSec peers. Also, for most hardware encryption engines, it is less efficient to encrypt transport mode than tunnel mode, because transport mode requires displacement of the IP header to make room for the ESP or AH header.
IPSec VPN service using transport mode and GRE encapsulation between the VPN gateways at each site is a very popular option for site-to-site VPNs. But what about an IP node that has no GRE support, yet requires the establishment IPSec VPN connectivity with another site? The most common example of this is a telecommuter. IPSec tunnel mode helps address this situation.
In tunnel mode, the original IP packet is encapsulated in another IP datagram, and an IPSec header (AH or ESP) is inserted between the outer and inner headers. Because of this encapsulation with an “outer” IP packet, tunnel mode can be used to provide security services between sites on behalf of IP nodes behind the gateway router at each site. Also, this mode can be used for the telecommuter scenario of connecting from an end host to an IPSec gateway at a site. Figure 2-4 shows an IP packet protected by IPSec in tunnel mode.
ESP provides confidentiality, data integrity, and optional data origin authentication and anti-replay services. It provides these services by encrypting the original payload and encapsulating the packet between a header and a trailer, as shown in Figure 2-5.
ESP is identified by a value of 50 in the IP header. The ESP header is inserted after the IP header and before the upper layer protocol header. The IP header itself could be a new IP header in tunnel mode or the original IP packet’s header in transport mode. Figures 2-6 and 2-7 show the position of the ESP header in transport and tunnel mode, respectively.
The security parameter index (SPI) in the ESP header is a 32-bit value that, combined with the destination address and protocol in the preceding IP header, identifies the security association (SA) to be used to process the packet. The SPI is an arbitrary number chosen by the destination peer during Internet Key Exchange (IKE) negotiation between the peers. It functions like an index number that can be used to look up the SA in the security association database (SADB).
The sequence number is a unique monotonically increasing number inserted into the header by the sender. Sequence numbers, along with the sliding receive window, provide anti-replay services. The anti-replay protection scheme is common to both ESP and AH.
The data being protected (or, more specifically, being encrypted by ESP) is in the payload data field. The algorithm used to encrypt the payload may require an initialization vector (IV), which is also carried in the data payload. Note that the IV is authenticated but not encrypted. If the encryption algorithm used is DES, then the first eight bytes of the protected data field is the IV; 3DES and AES also have an 8-byte IV.
Padding in the ESP header is the addition of bits to the ESP header; the number of bits to be padded depends on the encryption algorithm that is used. The Pad Length field indicates the number of pad bytes added so that the original data can be restored on decryption.
The next header payload identifies the type of data in the payload. For example, if ESP is used in tunnel mode, this value will be 4.
Authentication digest in the ESP header is used to verify data integrity. Because authentication is always applied after encryption, a check for validity of the data is done upon receipt of the packet and before decryption.
AH provides connectionless integrity, data authentication, and optional replay protection but, unlike ESP, it does not provide confidentiality. Consequently, it has a much simpler header than ESP. Figure 2-8 shows an AH-protected IP packet.
AH is an IP protocol, identified by a value of 51 in the IP header. The Next header field indicates what follows the AH header. In transport mode, it will be the value of the upper layer protocol being protected (for example, UDP or TCP). In tunnel mode, this value is 4. The positions of AH in transport and tunnel mode are shown in Figure 2-9 and Figure 2-10, respectively.
AH in transport mode is useful if the communication endpoints are also the IPSec endpoints. In tunnel mode, AH encapsulates the IP packet and an additional IP header is added before the AH header. Although the tunnel mode of AH could be used to provide IPSec VPN end-to-end security, there is no data confidentiality in AH and hence this mode is not too useful.
The payload length field in the AH header in Figure 2-9 indicates the length of the header. The Reserved field is not used, and is, therefore, set to zeroes. The SPI and sequence numbers have the same significance as in ESP. The authentication digest has one key difference from ESP: With AH, authentication is provided to the IP header in addition to the payload. As AH creates the authentication data on the entire packet, including the IP header, some of the IP fields will change in transit; therefore, all those fields in the IP header that may change in transit are zeroed out before the authentication digest is hashed. The fields that zero out include type of service (ToS) bits, flags, fragment offset, time-to-live (TTL), and header checksum. These fields are zeroed out because authenticating a changed value in transit (for example, TTL) will cause the authentication hash to have a mismatch from the sender and the packet will be dropped.
You learned that there are two types of encryption algorithms—symmetric 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).
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 p–1 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=ga mod p and Bob’s public value is Y=gb mod p. They then exchange their public values. Finally, Alice computes kab=(gb)a mod p, and Bob computes kba=(ga)b mod p. Because kab=kba=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=gab mod p given the two public values ga mod p and gb 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 key–based 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.
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 offers two modes—Main 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 consists of six messages—three in each direction—exchanged 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 that—it 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:
SKEYIDd= hashfunc(SKEYID, K|CI|CR|0) SKEYIDa hashfunc(SKEYID, SKEYIDd|K|CI|CR|1) SKEYIDe = hashfunc(SKEYID, SKEYIDa|K|CI|CR|2)
SKEYID is derived differently for each authentication where hashfunc(key, data) is the negotiated hash function using the key over the data mechanism. SKEYIDd is used to derive more keying material if such material is required and perfect forward secrecy (PFS) is not required. SKEYIDa is used as the key to provide data integrity for ISAKMP messages. SKEYIDe is used as the key for encryption of IKE messages.
The fifth and sixth messages are encrypted with SKEYIDe 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 SKEYIDe and SKEYIDa. The main part of the exchange is the identification of the initiator and responder IDi and IDr.
HASHi = hash(SKEYID, X|Y|Ci|Cr|SAr|IDi) HASHr = 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.
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.
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.
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.
In the case of digital signatures, peers can be authenticated with public key signatures—either 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.
SIGi= PRIVATEKEY_i(HASHi) SIGr = PRIVATEKEY_r(HASHr)
The key thing is the HASH_i and HASH_r are signed by the corresponding private keys to form the message digest SIGi and SIGr. 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 SKEYIDe; 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 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 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_a—the 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(SKEYIDd, 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(SKEYIDd, 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 peer—an 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.
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 traffic—inbound or outbound—between two IPSec peers. The SADB contains parameters that are associated with each (active) security association.
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.
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 triggers—one 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:
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.
In this chapter, you read an introduction to the IPSec architecture and explored concepts and terminology in enough detail to understand IPSec VPNs from a deployment and design perspective. You learned about the IPSec protocols ESP and AH and the difference between transport and tunnel mode, as well as how IKE and IPSec SAs are established between peers. You also saw how Cisco IOS processes IPSec packets.