IPsec Fundamentals - Secure Connectivity - Implementing Cisco IOS Network Security (IINS) Foundation Learning Guide, Second Edition (2013)

Implementing Cisco IOS Network Security (IINS) Foundation Learning Guide, Second Edition (2013)

Part IV: Secure Connectivity

Chapter 13. IPsec Fundamentals

This chapter addresses the protocols and algorithms that IPsec uses and the different security services that IPsec provides. More precisely, this chapter

• Analyzes the architecture of the IPsec protocol

• Details the role and operational impact of IPsec’s main components

• Describes IPsec modes of operation in various scenarios

• Describes the phases of IPsec connectivity

• Describes the role and component of IKE

• Provides an overview of the operations of IPv6 VPNs

An IP Security (IPsec) virtual private network (VPN) is an essential tool for providing a secure network for business communication. This chapter addresses the different protocols and algorithms that IPsec uses and the different security services that IPsec provides. This chapter also introduces the different VPN technologies and some of the best practices that you should use with them.

IPsec Framework

IPsec is an Internet Engineering Task Force (IETF) standard that defines how a VPN can be set up using the IP addressing protocol; it was originally defined in RFCs 2401 to 2412. IPsec works at the network layer, protecting and authenticating IP packets between participating IPsec devices (peers). IPsec is not bound to any specific encryption, authentication, or security algorithms or keying technology. IPsec is a framework of open standards.

Because IPsec is not bound to specific algorithms, IPsec allows newer and better algorithms to be implemented without patching the existing IPsec standards. IPsec provides data confidentiality, data integrity, origin authentication, and antireplay protection between participating peers at the IP layer. IPsec secures a path between a pair of gateways or between a gateway and a host, as shown in Figure 12-2 in Chapter 12, “Fundamentals of Cryptography and VPN Technologies.” IPsec could also secure a path between two hosts.

IPsec provides the following essential security functions:

Confidentiality: IPsec ensures confidentiality by using encryption. Data encryption prevents third parties from reading the data, especially data transmitted over public networks or over wireless networks.

Integrity: IPsec ensures that data arrives unchanged at the destination; that is, that the data has not been manipulated at any point along the communication path. IPsec ensures data integrity by using checksums, which are a simple redundancy check. The IPsec protocol adds up the basic components of a message, typically the number of bytes, and stores the total value. IPsec performs a checksum operation on received data and compares the result to the authentic checksum. If the sums match, the assumption is that the data has not been manipulated.

Authentication: Authentication ensures that the connection is made with the desired communication partner. IPsec uses Internet Key Exchange (IKE) to authenticate users and devices that can carry out communication independently. IKE uses several types of authentication:

• Username and password

• One-time password

• Biometric

• Preshared keys (PSK)

• Digital certificates


Note

IKE is discussed in more detail in the section, “IKE Protocol,” later in the chapter.


Antireplay protection: Antireplay protection verifies that each packet is unique and is not duplicated. IPsec packets are protected by comparing the sequence number of the received packets with a sliding window on the destination host or security gateway. A packet that has a sequence number that comes before the sliding window is considered either late or a duplicate packet. Late and duplicate packets are dropped.

Essential services provided by IPsec are as follows:

• Confidentiality

• Integrity

• Authentication

• Antireplay

The main reason we use IPsec is typically to provide confidentiality to our transmission. Confidentiality is reached by encrypting sensitive payload. The following explains the recent improvement to encryption.

Suite B Cryptographic Standard

In most cryptographic functions, the key length is an important security parameter. Both academic and private organizations provide recommendations and mathematical formulas to approximate the minimum key size requirement for security. Despite the availability of these publications, choosing an appropriate key size to protect systems and networks from attacks remains a challenge.

As computing power increases, the feasibility of deploying complex encryption algorithms commercially also increases. The main principle is that the degree of security depends on the length of the key of the encryption algorithm. The time that it takes to process all of the possibilities is a function of the computing power of the computer. Therefore, the shorter the key, the easier it is to break the key.

In 2005, the U.S. National Security Agency (NSA) identified a set of cryptographic algorithms that, when used together, provides the preferred method for ensuring the security and integrity of information that is passed over public networks such as the Internet. The NSA called the set of algorithms “Suite B.” Today, Suite B is globally recognized as an advanced, publicly available standard for cryptography. Suite B provides a security level of 128 bits or higher, significantly higher than many commonly used standards.

Integrated into IETF standards, Suite B algorithms make it easier to collaborate in environments where costs or logistics traditionally hindered information sharing. Secure sharing of information over the Internet and other nontrusted networks supports various missions at all levels of government. Examples include intelligence agencies and the military in a government context, or private sector companies that are required to increase the security of transmitting sensitive content such as intellectual property or private customer and employee information.

Another advantage of Suite B is that it helps public and private sector organizations meet compliance requirements. These requirements include compliance with Payment Card Industry Data Security Standard (PCI DSS), Health Insurance Portability and Accountability Act (HIPAA), Federal Information Processing Standards (FIPS), and others.

As described in RFC 4869, “Suite B Cryptographic Suites for IPsec,” Suite B cryptography secures information traveling over networks using four well-established, public-domain cryptographic algorithms:

• Encryption that is based on AES using 128- or 256-bit keys

• Digital signatures with the Elliptic Curve Digital Signature Algorithm (ECDSA) using curves with 256- and 384-bit prime moduli

• Key exchange, either preshared or dynamic, using the Elliptic Curve Diffie-Hellman (ECDH) method.

• Hashing (digital fingerprinting) based on Secure Hash Algorithm 2 (SHA-2)

The NSA has stated that these four algorithms in combination provide adequate information assurance for classified information. RFC 4869 has gained acceptance in the industry.


Note

In December 2006, NSA submitted an Internet Draft on implementing Suite B for IPsec, which was accepted for publication by the IETF as RFC 4869. However, RFC 4869 was later obsoleted by RFC 6379 in October 2011. The curriculum of IINSv2 exam 640-554 was developed with RFC 4869 in mind.

Also note that with the use of 384-bit elliptic curve, SHA-384 and AES with 256-bit keys are necessary for the protection of top secret information.


Commercial Suite B devices do not require the special handling requirements that are traditionally associated with government-specific cryptographic devices. The less stringent requirements simplify adoption, strengthen the overall architecture security, and minimize operational costs.

Essential services provided by the Suite B cryptographic standard include the following:

• Confidentiality = AES

• Integrity = SHA-2

• Authentication = ECDSA

• Key management = ECDH

Encryption Algorithms

Chapter 12 provided an in-depth analysis of the different encryption technologies. You saw that the degree of security depends on the length of the key and on the encryption algorithm. The time that it takes to process all the possibilities is a function of the computing power of the computer. Therefore, the shorter the key, the easier it is to break the key.

The following are some of the encryption algorithms and key lengths that VPNs use:

Date Encryption Standard (DES): DES was developed by IBM. DES uses a 56-bit key, ensuring high-performance encryption. DES is a symmetric key cryptosystem.

3DES: The 3DES algorithm is a variant of the 56-bit DES. 3DES operates in a way that is similar to how DES operates, in that data is broken into 64-bit blocks. 3DES then processes each block three times, each time with an independent 56-bit key. 3DES provides significant encryption strength over 56-bit DES. 3DES is a symmetric key cryptosystem.

Advanced Encryption Standard (AES): The National Institute of Standards and Technology (NIST) has recently adopted AES to replace the existing DES encryption in cryptographic devices. AES provides stronger security than DES and is computationally more efficient than 3DES. AES offers three different key lengths: 128-, 192-, and 256-bit keys. AES is the standard prescribed in RFC 4869, “Suite B Cryptographic Suites for IPsec.”

Rivest, Shamir, and Adleman (RSA): RSA is an asymmetrical key cryptosystem. It uses a key length of 512, 768, 1024, or larger. IPsec does not use RSA for data encryption. IKE uses RSA encryption only during the peer-authentication phase.

Software-Optimized Encryption Algorithm (SEAL) algorithm: SEAL is a stream cipher, developed in 1993 by Phillip Rogaway and Don Coppersmith, and uses a 160-bit key for encryption.

Key Exchange: Diffie-Hellman

Encryption algorithms, such as DES and 3DES, explained in Chapter 12, require a symmetric shared-secret key to perform encryption and decryption. You can use email, courier, or overnight express to send the shared-secret keys to the administrators of the devices. But the easiest key-exchange method is a public-key exchange method between the encrypting and decrypting devices. The method has two variants:

• The Diffie-Hellman (DH) key agreement, explained in great detail in Chapter 12, is a cryptographic protocol that provides a way for two peers to establish a shared-secret key, which only they know, even though they are communicating over an unsecure channel.

• ECDH is a variant of the DH protocol using elliptic curve cryptography (ECC). It is part of the Suite B standards.

That shared-secret key, created by the Diffie-Hellman key exchange method, is then used as the encryption key to exchange data.

These algorithms are used within IKE to establish session keys. They support different key sizes that are identified by different DH or ECDH groups. DH groups determine the strength of the key that is used in the key exchange process. Higher group numbers are more secure, but they require additional time to compute the key. The DH groups are referred to as DHx; for example, Diffie-Hellman Group 1 is referred to as DH1. The following is a quick listing of the different DH groups (which are covered in more detail later in this chapter, in the “IKE Protocol” section):

• DH1: 768-bit key

• DH2: 1024-bit key

• DH5: 1536-bit key

• DH7: 163-bit ECDH key

• DH14: 2048-bit key

• DH15: 3072-bit key

• DH16: 4096-bit key

• DH19: 256-bit ECDH key

• DH20: 384-bit ECDH key

• DH24: 2048-bit ECDH key

Data Integrity

VPN data is typically transported over the public Internet. Potentially, this data could be intercepted and modified. To guard against this problem, you can use a data-integrity algorithm, explained in Chapter 12. A data-integrity algorithm adds a hash to the message, which guarantees the integrity of the original message. If the transmitted hash matches the received hash, the message has not been tampered with. However, if there is no match, the message was altered.

A Hashed Message Authentication Code (HMAC) is a data-integrity algorithm that guarantees the integrity of the message. At the local end, the message and a shared-secret key are sent through a hash algorithm, which produces a hash value. The message and hash are sent over the network. Refer to Figure 12-18 in Chapter 12 for a detailed presentation on HMAC.

General HMAC concepts were explained in Chapter 12. Now, let’s look at three common HMAC algorithms:

HMAC-Message Digest 5 (HMAC-MD5): HMAC-MD5 uses a 128-bit shared-secret key of any size. The variable-length message and shared-secret key are combined and run through the HMAC-MD5 hash algorithm. The output is a 128-bit hash. The hash is appended to the original message and is forwarded to the remote end.

HMAC-Secure Hash Algorithm 1 (HMAC-SHA-1): HMAC-SHA-1 uses a secret key of any size. The variable-length message and the shared-secret key are combined and run through the HMAC-SHA-1 hash algorithm. The output is a 160-bit hash. The hash is appended to the original message and is forwarded to the remote end.

HMAC-Secure Hash Algorithm 2 (HMAC-SHA-2): The SHA-2 family of HMACs is based on the same base algorithm as SHA-1. The SHA-2 family (the second generation of SHA algorithms) includes the algorithms of 256 and 384 bit, referred to as SHA-256 bit hash algorithm and SHA-384 bit hash algorithm. This functionality is part of the Suite B standard.

Authentication

When you are conducting business long distance, it is necessary to know who is at the other end of the phone, email, or fax. The same is true of VPN networks. The device on the other end of the VPN tunnel must be authenticated before the communication path is considered secure. Four peer-authentication methods exist:

Preshared keys: A secret key value is entered into each peer manually and is used to authenticate the peer. This is a shared secret that both parties must exchange ahead of time. Think of it as a secret password that they offer to each other to confirm the identity of the other party. At each end, the PSK is combined with other information to form the authentication key.

RSA signatures: In addition to sending its digital certificate to the remote end, the sender also includes the hash value of a message encrypted with its private key. This acts like a signature. At the remote end, once the receiver has validated the sender’s digital certificate, the encrypted hash is decrypted using the public key of the sender, found in the sender’s digital certificate. If the decrypted hash matches the recomputed hash, the signature is genuine.

RSA encrypted nonces: A nonce is a random number generated by the peer. It is similar to a nonce word, used only once. RSA encrypted nonces use RSA to encrypt the nonce value and other values. This method requires that the public key of the two peers be present on the other peer before the third and fourth messages of an IKE exchange can be accomplished. For this reason, public keys must be manually copied to each peer as part of the configuration process, and therefore this method is limited by the available memory of the receiver. This method is the least used of the four authentication methods.

Elliptic Curve Digital Signature Algorithm (ECDSA): The ECDSA is the elliptic curve analog of the DSA, which is part of the Digital Signature Standard (DSS) method. ECDSA signatures are smaller than RSA signatures of similar cryptographic strength. ECDSA public keys (and certificates) are smaller than similar-strength DSA keys, resulting in improved communications efficiency. Furthermore, on many platforms, ECDSA operations can be computed more quickly than similar-strength RSA operations. These advantages of signature size, bandwidth, and computational efficiency may make ECDSA an attractive choice for many IKE and IKE version 2 (IKEv2) implementations.

IPsec is a framework of open standards. IPsec spells out the messaging to secure the communications but relies on existing algorithms to implement the encryption, authentication, and key exchange. Figure 13-1 illustrates some of the standard algorithms that IPsec uses.

Figure 13-1. IPsec Framework Components

When you configure an IPsec gateway to provide security services, you will call from the components that make the IPsec framework. This framework includes IPsec protocols and many other categories of components, as shown in Figure 13-1. You must first choose an IPsec protocol. The choices are Encapsulating Security Payload (ESP) or ESP with Authentication Header (AH). AH can also be used alone. The second element is an encryption algorithm. Choose the encryption algorithm that is appropriate for the desired level of security: DES, 3DES, or AES. The third element is authentication. Choose an authentication algorithm to provide data integrity: MD5 or SHA. The last element is the DH algorithm group. Choose which group to use, DH Group 1 (DH1), DH Group 2 (DH2), or DH Group 5 (DH5). IPsec provides the framework, and the administrator chooses the algorithms that are used to implement the security services within that framework.

IPsec Protocol

IPsec is a framework of open standards. There are two distinct stages to building IPsec tunnels: IKE and the IPsec protocol itself. IKE is responsible for establishing the rules of engagement and confirming the identity of the peers with whom communication is about to start. IPsec tunnels are responsible for passing data in a secure communication. To make an analogy, consider the FTP protocol, which uses two ports. Port 21 is used as the control port and port 20 is used as the data port. Port 21 is responsible for validating the identity of the parties and negotiating the requests. The actual data (file) exchange is done through the data port, port 20. The process is similar with the IPsec framework. IKE has a similar role as port 21, with responsibility for negotiating the type of connection, the identity of the entities, and so forth. IPsec tunnels are similar to port 20, because they are the secured carrier of the data exchanged between the two peers (the procedure for which will be covered in detail later in this chapter). Think of IKE as the control plane and IPsec as the data plane. For now, let’s focus on the actual tunnels that provide secure data exchanges between peers, the actual IPsec tunnels.

IPsec spells out the messaging to secure the communications but relies on existing algorithms, listed in Figure 13-1. There are two main IPsec framework protocols, as depicted in Figure 13-2:

Authentication Header (AH): AH, which is IP protocol 51, is the appropriate protocol to use when confidentiality is not required or permitted. It provides data authentication and integrity for IP packets passed between two systems. It is a means of verifying that any message that is passed from Router A to Router B has not been modified during transit. It verifies that the origin of the data was either Router A or Router B. AH does not provide data confidentiality (encryption) of packets. All text is transported in the clear. If the AH protocol is used alone, it provides weak protection. Consequently, Encapsulating Security Payload uses the AH protocol to provide data encryption and tamper-aware security features.

Encapsulating Security Payload (ESP): ESP is a security protocol that can provide confidentiality and authentication. ESP, which is IP protocol 50, provides confidentiality by performing encryption on the IP packet. IP packet encryption conceals the data payload and the identities of the ultimate source and destination. ESP provides authentication for the inner IP packet and ESP header. Authentication provides data-origin authentication and data integrity. Although both encryption and authentication are optional in ESP, at a minimum, one of them must be selected.

Figure 13-2. IPsec Security Protocols

Authentication Header

AH achieves authenticity by applying a keyed one-way hash function to the packet to create a hash, or message digest. The hash is combined with the text and is transmitted. The receiver detects changes in any part of the packet that occur during transit by performing the same one-way hash function on the received packet and comparing the result to the value of the message digest that the sender has supplied. The fact that the one-way hash also involves the use of a shared-secret key between the two systems means that authenticity is assured.

The AH function is applied to the entire datagram except for any mutable IP header fields that change in transit; for example, Time to Live (TTL) fields that are modified by the routers along the transmission path. Figure 13-3 illustrates the AH process, which is as follows.

Figure 13-3. AH Authentication and Integrity

Step 1. The IP header and data payload are hashed.

Step 2. The hash builds a new AH header, which is prepended to the original packet.

Step 3. The new packet is transmitted to the IPsec peer router.

Step 4. The peer router hashes the IP header and data payload, extracts the transmitted hash from the AH header, and compares the two hashes. The hashes must match exactly. Even if 1 bit is changed in the transmitted packet, the hash output on the received packet changes and the AH header will not match.

AH supports the HMAC-MD5 and HMAC-SHA-1 algorithms.


Note

AH protects the entire IP packet, which includes the IP header, against tampering during transmission. Because NAT modifies the IP header, it is incompatible with AH. Fixes, such as tunnel mode, discussed later, remedy this problem.

Also, note that the Cisco firewalls, starting at code 7, do not offer the AH option. Only ESP can be performed.


Essential services provided by AH are

• Data integrity through hashing

• Data origin authentication through hashing

• Antireplay protection


AH in Production

AH has its place for secure communication. When most of us hear the term “secure communication,” we think encrypted payload. However, there are situations where confidentiality is not necessary but authenticity and integrity are. Take the example of a car manufacturer that places an order to its brake pads supplier every morning at 8 a.m. for just-in-time delivery the next day. There is nothing secret about today’s order of 8000 brake pads. So, payload encryption is not necessary. However, the brake pads supplier, upon receiving the order, wants to confirm that the order really came from the car manufacturer and not from Johnny the Joker, and that the order of 8000 brake pads wasn’t tampered with. The order for 8000 brake pads would be released with the payload in cleartext; however, an encrypted hash of the packet is included in the transmission, thus providing a proof of origin and integrity.


Encapsulating Security Payload

ESP provides confidentiality by encrypting the payload. It supports a variety of symmetric encryption algorithms. The lowest common algorithm for IPsec is 56-bit DES. Cisco products also support the use of 3DES and especially AES for stronger encryption.

ESP can also provide integrity and authentication of the datagrams. First, the payload is encrypted. Next, the encrypted payload is sent through a hash algorithm, HMAC-MD5 or HMAC-SHA-1. The hash provides authentication and data integrity for the data payload.

Optionally, ESP can also enforce antireplay protection by requiring that a receiving host set the replay bit in the header to indicate that the packet has been seen.

The original data is well protected by ESP because the entire original IP datagram is encrypted, as shown in Figure 13-4. An ESP header and trailer are added to the encrypted payload. With ESP authentication, the encrypted IP datagram and the ESP header and trailer are included in the hashing process. Lastly, a new IP header is prepended to the authenticated payload. The new IP address is used to route the packet through the Internet.

Figure 13-4. ESP Protocol

When both authentication (AH) and encryption (ESP) are selected, encryption occurs first. One reason for this order of processing is that it facilitates rapid detection and rejection of replayed or bogus packets by the receiving device. Before decrypting the packet, the receiver can authenticate inbound packets. By doing this, it can quickly detect problems and potentially reduce the impact of denial-of-service (DoS) attacks.

Essential services provided by ESP are

• Data confidentiality through encryption

• Data integrity through hashing

• Data origin authentication through hashing

• Antireplay protection

IPsec Modes of Operations

ESP and AH can be used in two different ways, or modes. The encapsulation can be done in tunnel mode or in transport mode. The encapsulation performed on an ESP packet with each mode is illustrated in Figure 13-5.

Figure 13-5. Encapsulation with Tunnel Mode and Transport Mode

Transport Mode

In transport mode, security is provided only for the transport layer and above. Transport mode protects the payload of the packet but leaves the original IP address in the clear. The original IP address is used to route the packet through the Internet. ESP transport mode is used between hosts and is therefore not compatible with Network Address Translation (NAT).


Note

Transport mode works well with generic routing encapsulation (GRE) because GRE hides the addresses of the end stations by adding its own IP header.


Tunnel Mode

ESP tunnel mode provides security for the complete original IP packet. The original IP packet is encrypted, and then it is encapsulated in another IP packet. The outside IP address is used to route the packet through the Internet.

ESP tunnel mode is used between a host and a security gateway or between two security gateways, as shown in Figure 13-6. For gateway-to-gateway applications, rather than load IPsec on all the computers at the remote and corporate offices, it is easier to have the security gateways perform the IP-in-IP encryption and encapsulation.

Figure 13-6. IPsec Tunnel Mode

ESP tunnel mode is used in the IPsec remote-access application. At a home office, there might be no router to perform the IPsec encapsulation and encryption. In this case, an IPsec client running on the PC performs the IPsec IP-in-IP encapsulation and encryption. At the corporate office, the router de-encapsulates and decrypts the packet.

IKE Protocol

IPsec implements a VPN solution using an encryption process that involves the periodic changing of encryption keys. IPsec uses the IKE protocol to authenticate a peer computer and to generate encryption keys. IKE negotiates a security association (SA), which is an agreement between two peers engaging in an IPsec exchange and consists of all the required parameters necessary to establish successful communication. An IPsec peer accepting incoming IKE requests listens on UDP port 500.

IPsec uses the IKE protocol to provide these functions:

• Negotiation of SA characteristics

• Automatic key generation

• Automatic key refresh

• Manageable manual configuration

There are two versions of the IKE protocol: IKEv1 and IKEv2. IKEv2 was created to overcome some of the limitations of IKEv1. IKEv2 provides the following enhancements:

• Simplicity, by requiring fewer transactions to establish security associations. A simplified initial exchange of messages reduces latency and increases connection establishment speed.

• Stronger security, through DoS protection and other functions.

• Reliability, by using sequence numbers, acknowledgements, and error correction.

• Flexibility, through support for Extensible Authentication Protocol (EAP) as a method for authenticating VPN endpoints.

• Mobility, by using the IKEv2 Mobility and Multihoming Protocol (MOBIKE) extension. This enhancement allows mobile users to roam and change IP addresses without disconnecting their IPsec session.

Because the IKEv2 base specification includes all the functionality of IKEv1, we’ll look at the IKEv1 modes and phases first, followed by a brief overview of the enhancements in IKEv2, and then summarize the differences between these two versions.


Note

Because a picture is worth a thousand words, Figure 13-7 is the visual representation of IPsec sequence of events when tunnels are being built with IKEv1. The process starts at the bottom of the figure with IKE Phase 1, followed by IKE Phase 2, and finally with the two unidirectional IPsec tunnels coming up to exchange the encrypted data.

Figure 13-7. Visual Representation of IKEv1 and IPsec Tunnels Being Built from the Ground Up


IKEv1 Modes

To establish a secure communication channel between two peers, the IKE protocol uses the following three modes of operation:

Main mode: In main mode, which takes place in IKEv1 Phase 1, an IKE session begins with one computer (the initiator) sending a proposal or proposals to another computer (the responder). The proposal sent by the initiator defines what encryption and authentication protocols are acceptable, how long keys should remain active, and whether Perfect Forward Secrecy (PFS) should be enforced. (PFS is covered later in this chapter.) There are three exchanges typical of main mode, for a total of six packets:

• The first exchange between the initiator and the responder establishes the basic security policy. The initiator sends all its Internet Security Association and Key Management Protocol (ISAKMP) policies. The responder chooses a proposal best suited to the security situation and then sends that proposal to the initiator. This exchange totals two packets.

• The next exchange passes DH public keys between the two users. DH key exchange is a cryptographic protocol that allows two parties that have no prior knowledge of each other to establish a shared-secret key over an unsecure communications channel. All further negotiation is encrypted within the IKE SA.

• The third exchange authenticates an ISAKMP session. The fifth and sixth packets are the first packets exchanged encrypted, as depicted earlier in Figure 13-7, which shows authentication being conducted inside the ISAKMP tunnel. Once the IKE SA is established, IPsec quick mode negotiation begins.

Aggressive mode: Aggressive mode compresses into three packets the IKE SA negotiation phases just described. In aggressive mode, which takes place in IKEv1 Phase 1, the initiator passes all data that is required for the SA. The responder sends the proposal, key material, and ID and authenticates the session in the next packet. The initiator replies by authenticating the session. Negotiation is quicker, and the initiator and responder IDs pass in plaintext.

Quick mode: Quick mode IPsec negotiation, which happens in IKEv1 Phase 2, takes place after successful IKE SA negotiation. Quick mode is similar to aggressive mode IKE negotiation, except that negotiation is protected within an IKE SA. Quick mode negotiates the SA for the data encryption and manages the key exchange for that IPsec SA, as shown in Figure 13-7. This means that it negotiates a shared IPsec transform, derives shared-secret keying material that the IPsec security algorithms will use, and establishes IPsec SAs. During quick mode, the peers exchange the list of protected networks: the subnets at each end that must use the encrypted tunnel when communicating amongst themselves.

IKEv1 Phases

To establish a secure communication channel between two peers, the IKE protocol executes the following phases:

IKE Phase 1: Two IPsec peers perform the initial negotiation of SAs. In this phase, the SA negotiations are bidirectional; data may be sent and received using the same encryption key. In IKE Phase 1, the transform sets, hash methods, and other parameters are determined. Optionally, IKE Phase 1 can include authentication, in which each peer in the SA negotiation is able to verify the identity of the other. Even if the SA negotiation data stream between the two IPsec peers is compromised, there is little chance that the encryption keys could be guessed and thus the traffic decrypted.

IKE Phase 2: SAs are negotiated by the IKE process ISAKMP on behalf of other services, such as IPsec, that need encryption key material for operation. Quick mode negotiates the IKE Phase 2 SAs. In this phase, the SAs that IPsec uses are unidirectional; therefore, a separate key exchange is required for each data flow.


Note

Other, optional parameters are sometimes negotiated between IKE Phase 1 and IKE Phase 2, such as level of DH, encryption algorithms, and methods of authentication.


IKEv1 Phase 1

The basic purpose of IKE Phase 1, shown in Figure 13-8, is to negotiate IKE policy sets, authenticate the peers, and set up a secure channel between the peers. IKE Phase 1 occurs in two modes: main mode and aggressive mode.

Figure 13-8. IKE Phase 1

Main Mode

Main mode has three two-way exchanges between the initiator and receiver:

First exchange: Peers negotiate and agree on the algorithms and hashes that will be used to secure the IKE communications.

Second exchange: DH generates public and private values. The peers exchange their public values, and the result is a shared secret. The shared-secret key is used to generate all the other encryption and authentication keys.

Third exchange: The identity of the other side is verified. The main outcome of main mode is a secure communications path for subsequent exchanges between the peers.


Note

In aggressive mode, fewer exchanges are done, and the exchanges have fewer packets. As an example, with aggressive mode, the peers will exchange their identity and a hash of the PSK even though the DH calculations have not been performed yet, and therefore there is no shared secret to send data in an encrypted format.


Aggressive Mode

Aggressive mode, as explained earlier, compresses the IKE SA negotiation phases into a total of three messages. Negotiation is quicker, and the initiator and responder IDs pass in plaintext.

Main Mode Versus Aggressive Mode

The use of main mode or aggressive mode is a tradeoff between performance and security. Main mode requires more messages but does not expose the identity of the peers. This identity is protected by the policies and keys that are negotiated in the first two exchanges. Aggressive mode requires fewer messages and therefore is more efficient. However, peer identities are exposed before negotiating a secure channel, so it assumes a trusted transport and a more protected environment outside of IPsec. The choice of mode is a configurable option in most IPsec implementations.

IKEv1 Phase 1 Example

When you are trying to make a secure connection between Host A and Host B through the Internet, a secure path (a tunnel) is established between Router A and Router B. Through the tunnel, the IPsec encryption, authentication, and other protocols are negotiated.

IKEv1 First Exchange: IKE Policy Is Negotiated

The ultimate goal of IPsec is to have a secure tunnel through which we can transmit encrypted data. Before we start exchanging encrypted data with a peer, though, we need to confirm who we are dealing with and how we will be sending encrypted data to it. You would never send your credentials in cleartext to your peer for authentication, so IPsec needs to start with transmission of other information in cleartext. This is the beginning of IKEv1 Phase 1.

In the cleartext, the two peers agree on the following:

Encryption algorithm they will use for their IKE tunnel: DES, 3DES, or EAS

Hashing algorithm they will use for integrity check: MD5 or SHA

Authentication method they will use: PSK, RSA Signatures, RSA encrypted nonces, or ECDSA

DH group: The DH group used to generate the symmetrical key used to encrypt IKE traffic between the two peers, such as authentication credentials, which shouldn’t be sent in cleartext. An IKE tunnel is made of different protocols, one of which is called Internet Security Associate Key Management Protocol (ISAKMP). ISAKMP is an encrypted tunnel through which peers will be exchanging, among other things, their credentials. To have an encrypted tunnel, both peers must have the same symmetrical key. The DH group designates the length of the symmetrical key that will be generated during the upcoming Diffie-Hellman operation.

Duration of ISAKMP tunnel: This is referred to as the lifetime.


IKE HAGLE

Use the acronym HAGLE to assist you in remembering the five elements that peers agree upon during IKEv1 Phase 1:

H = Hash

A = Authentication

G = Group (DH group)

L = Lifetime

E = Encryption


Rather than negotiate each protocol individually, the protocols are grouped into sets, called IKE policy sets. IKE policy sets are exchanged during the IKE main mode, first exchange phase. If a policy match is found between peers, main mode continues. If no match is found, the tunnel is torn down.

Of the five values that both peers must agree on, only lifetime can be adjusted dynamically. It will be adjusted to the smallest values exchanged between the two peers. All the other elements of IKEv1 Phase 1 negotiations (hash, authentication, DH group, encryption) must have a perfect match between the two peers.

In Figure 13-9, Router A sends IKE policy sets 10, 20, and 30 to Router B. Router B compares its sets with those received from Router A. In this instance, there is a policy match. Policy set 10 of Router A matches policy set 20 of Router B and is selected over policy set 30 on both sides, because the lowest policy priority number wins.

Figure 13-9. IKEv1 Phase 1, First Exchange: Policy Is Negotiated


Note

Policy set numbers are only locally significant to a VPN device. The policy set numbers do not have to match between two VPN peers.


In a point-to-point application, each end may need only a single IKE policy set to be defined. However, in a hub-and-spoke environment, the central site may require multiple IKE policy sets to satisfy all the remote peers.

IKEv1 Second Exchange: DH Key Exchange

When the IKE policy is agreed on, including the size of the prime number to be used for DH, the two peers run the DH key exchange protocol. You will remember from Chapter 12 that, as shown in Figure 13-10, the result of DH will be the creation of a shared secret, where K = K′, that is needed by the various symmetric encryption and hashing algorithms upon which IKE and IPsec will ultimately agree.

Figure 13-10. IKEv1 Phase 1, Second Exchange: DH Key Exchange

Several levels of DH key exchanges are available in Cisco IOS Software:

DH Group 1: A key exchange that uses a 768-bit prime number. This group is the usual choice when the encryption algorithm is DES.

DH Group 2: A key exchange that uses a 1024-bit prime number. This group is the usual choice when using 3DES for encryption.

DH Group 5: A key exchange that uses a 1536-bit prime number. DH 5 should be used with AES.

DH Group 7 (ECC): A key exchange that generates IPsec keys when the elliptic curve field is 163 bits. This group was designed to be used with low-powered hosts such as PDAs.

DH Group 14: A key exchange that results in 2048 bits of keying material.

DH Group 15: A key exchange that results in 3072 bits of keying material.

DH Group 16: A key exchange that results in 4096 bits of keying material.

DH Group 19: A key exchange that results in 256 bits of keying material.

DH Group 20: A key exchange that results in 384 bits of keying material.

DH Group 24: A key exchange that results in 2048 bits of keying material.


Note

Groups 5, 14, 15, and 16 should be used with AES. Groups 19, 20, and 24 should be used with ECDH.


The group that is chosen must be strong enough (have enough bits) to protect the IPsec keys during negotiation. A generally accepted guideline recommends the use of a 2048-bit group after the year 2013 (until the year 2030). Either DH14 or DH24 can be selected to meet this guideline. Even if a longer-lived security method is needed, the use of ECC is recommended, but G15 and DH16 can also be considered.

IKEv1 Third Exchange: Authenticate Peer Identity

When you are conducting business over the Internet, it is necessary to know who is at the other end of the tunnel. The device on the other end of the VPN tunnel must be authenticated before the communications path is considered secure. The last exchange of IKE Phase 1 authenticates the remote peer, as illustrated in Figure 13-11.

Figure 13-11. IKEv1 Phase 1, Third Exchange: Authenticate Peer Identity

As mentioned earlier, there are four data origin authentication methods with IKEv1:

PSKs: Pre-shared keys are a secret key value that is entered into each peer manually and is used to authenticate the peer.

RSA signatures: RSA signatures are the exchange of digital certificates that is used to authenticate the peers in addition to sending a hash value of a message encrypted with its private key as proof of its identity.

RSA encrypted nonces: Nonces are random numbers that are generated by each peer and then encrypted and exchanged between peers. The two nonces are used during the peer-authentication process.

ECDSA signatures: Exchange of certificates. ECDSA certificates are smaller than RSA signatures of similar cryptographic strength, resulting in improved communications efficiency. ECDSA is available with Suite B.

IKEv1 Phase 2

The purpose of IKEv1 Phase 2 is to negotiate the IPsec security parameters, as shown in Figure 13-12, that will be used to secure the IPsec tunnel. IKEv2 Phase 2 performs the following functions.

Figure 13-12. IKE Phase 2

• Negotiates IPsec security parameters, known as IPsec transform sets.

• Establishes IPsec SAs.

• Periodically renegotiates IPsec SAs to ensure security.

• Optionally, performs an additional DH exchange to generate IPsec SA keys that have no relation to the IKE keys. Generating IPsec keys from scratch for the purpose of IPsec SAs is referred to as Perfect Forward Secrecy (PFS), which is described after IKEv2 quick mode.

IKEv2 Quick Mode

IKE Phase 2 has one mode, called quick mode. Quick mode occurs after IKE has established the secure tunnel in Phase 1. It negotiates a shared IPsec transform, derives shared-secret keying material that the IPsec security algorithms will use, and establishes IPsec SAs. Quick mode also exchanges nonces that are used to generate new shared-secret key material and to prevent replay attacks from generating false SAs.

Quick mode also renegotiates a new IPsec SA when the IPsec SA lifetime expires. Basically, quick mode refreshes the keying material that creates the shared-secret key, which is based on the keying material derived from the DH exchange in Phase 1.

Perfect Forward Secrecy

The basic principle of PFS is that new keys (shared secrets) cannot be derived from older keys. The idea is that if keys are compromised, previous and subsequent keys are secured because they were generated from scratch and not derived. Therefore, PFS exists when a DH exchange is done at each rekeying interval, which is preferable, but might not be necessary, instead of deriving the new keys from the previous keys.

IKE Version 2

In IKEv2, there is a simplified initial exchange of messages that, compared to IKEv1, reduces latency and increases the connection establishment speed. The IKEv2 base specification includes all the functionality of IKEv1 as well as additional functionality. It preserves most of the features of version 1, including the two negotiation phases. However, the specific operations of the two phases differ:

Phase 1: In IKEv2, there is only one mode or set of network flows defined for Phase 1 negotiation. The set requires four messages, two from the initiator and two from the responder. The first two of these four messages flow in the clear on the network. The other two messages are encrypted. Still, this mode is equivalent to main mode in IKEv1, and not to aggressive mode.

The negotiation of the first Phase 2 SA is accomplished within these four flows, still in Phase 2. When the fourth message flows, both Phase 1 and Phase 2 SAs are activated. Either the initiator or the responder can later activate additional Phase 2 SAs using this Phase 1 SA.

Phase 2: The purpose of Phase 2 negotiation is to establish a set of parameters, known as an SA, which is used to protect specific types of IP traffic. The Phase 2 SA contains the keys that are used to encrypt and decrypt IPsec packets on the host, authenticate IPsec packets on the host, or both. Because the first Phase 2 SA is created during Phase 1, all subsequent Phase 2 SAs are called child SAs. The identity of the remote peer is implicitly authenticated when the Phase 2 SA is used.

IKEv2, illustrated in Figure 13-13, uses fewer messages to accomplish the same (and more) objectives as IKEv1. In addition, the parent-child relationship of Phase 2 SAs streamlines the process. The first Phase 2 SA is created during phase 1, and negotiated parameters are added here for child Phase 2 SAs.

Figure 13-13. IKEv2: A Simplified Approach

For instance, rekeying in IKEv2 negotiates new keys, but it does not reauthenticate the identity of the peer. When an IKEv1 Phase 1 SA is refreshed, new keys are negotiated, and identity of the IKE peer is reauthenticated.

IKEv1 Versus IKEv2

A full lecture on IKEv2 is beyond the scope of this book; however, Table 13-1 provides you with a summary of the differences between IKEv1 and IKEv2.

Table 13-1. Differences Between IKE Version 1 and Version 2

The notable differences with IKE version 2 are

Fewer RFCs: The specifications for IKEv1 were covered in at least three RFCs and even more. IKEv2 combines the specifications into one RFC.

Simplified message exchange: IKEv2 has one four-message initial exchange mechanism while IKEv1 provides eight distinctly different initial exchange mechanisms, each one of which has slight advantages and disadvantages.

Security: Identities are always hidden during Phase 1 in IKEv2. DoS attacks are mitigated because IKEv2 does not process a request until it determines the requester. IKEv1 can be tricked to perform much cryptographic (and expensive) processing from false locations (spoofing).

NAT traversal (NAT-T): ESP as is couldn’t be used with PAT because there are no ports that could be translated by the Internet-facing router configured for PATting outbound connections. To mitigate this problem, NAT-T was created. VPN clients, sitting behind a PAT device, encapsulate IKE and ESP in UDP port 4500, which enables these protocols to pass through a device performing NAT. NAT-T is used by both IKEv1 and IKEv2.

Reliability: IKEv2 uses sequence numbers and acknowledgments to provide reliability and mandates some error processing logistics and shared state management.

Support for EAP: By using EAP, IKEv2 can leverage existing authentication infrastructure and credential databases. EAP allows users to choose a method suitable for existing credentials, and also makes separation of the IKEv2 responder (VPN gateway) from the EAP authentication endpoint (backend authentication, authorization, and accounting [AAA] server) easier.

Mobility: Through MOBIKE, IKEv2 allows for Layer 3 roaming that changes the peer’s IP address. The main scenario for MOBIKE is enabling a remote-access VPN user to move from one address to another without reestablishing all SAs with the VPN gateway. For instance, a user could start from fixed Ethernet in the office and then disconnect the laptop and move to the office wireless LAN. When the user leaves the office, the laptop could start using General Packet Radio Service (GPRS). When the user arrives home, the laptop could switch to the home wireless LAN.

IPv6 VPNs

IPsec is the baseline protocol that was established for enabling packet security during transmission of packets in IPv6. Even though the IPv6 standards mandate that IPsec be implemented, they do not mandate that IPsec be used for all IPv6 communications. Such a mandate might not be realistic, given the limited computing resources of a personal digital assistant (PDA), telephone, printer, sensor, toaster, or refrigerator. These small embedded devices can lack the computing resources to perform encryption functions.

IPsec is also native to IPv6. It defines new protocol headers that add authentication and confidentiality to IPv6 packets. The original IPsec RFCs defined the use of an AH to secure the header information and the content of the packet and the use of an ESP to secure the contents of the packet. The IPsec architecture for IPv4 and the IPsec architecture for IPv6 are similar as far as the standards are concerned. In IPv4, AH and ESP were IP protocol headers. The difference is that IPv6 uses the extension header approach, as learned in the CCNA and as shown in Figure 13-14. In IPv6, ESP uses the next-header value of 50 and AH uses the next-header value of 51.

Figure 13-14. IPv6 Extension Header Approach

Because of the ubiquitous nature of the IPv6 Internet (at least in the future), some of the more recent features and functionalities that are found in IPsec become crucial when the protocol is used in IPv6 networks. The latest cryptography suites (Suite B and beyond) and the mobility enhancements that are found in IKEv2 are key.

Here is a summary of IPsec for IPv6 characteristics:

• IPsec is mandatory for IPv6.

• IPsec is native to IPv6.

• Includes built-in confidentiality, integrity, authentication, and antireplay.

• Offers flexibility and low overhead through extension headers.

• The IPsec framework and behavior are the same as IPsec for IPv4.

• Strong encryption (Suite B) and mobility enhancements (IKEv2) are key in IPv6.

• Only site-to-site tunnel mode VPNs are supported in Cisco IOS as of version 15.1.

IPsec Services for Transitioning to IPv6

In the early stages of the transition to IPv6, much of the world’s networks and the Internet will continue to use IPv4. Several options are available for transitioning to IPv6. Some of them involve tunneling IPv6 in IPv4 (such as manual IPv6 tunnels, automatic IPv4-compatible tunnels, GRE, automatic 6to4 tunnels, and Intra-Site Automatic Tunnel Addressing Protocol [ISATAP] tunnels).

Using these methods, you can transport IPsec-protected IPv6 traffic over an IPv4 WAN. If you only have IPv4 connectivity between your remote locations and your central site, you can use a tunnel. The tunnel interface can carry the IPv6 packets within an IPv4 tunnel.

Figure 13-15 shows the resulting packet structure. The IPv4 packet is encapsulated by IPsec with a header and a trailer. The result is encapsulated with an IPv4 header that allows forwarding across the IPv4 Internet. The recommended IPsec mode (per RFC 4891) is transport mode.

Figure 13-15. IPv6 Transition Using IPv6-over-IPv4 Tunnel

ESP uses the next-header value of 50 and AH uses the next-header value of 51.

Solutions for transitioning IPsec services to IPv6 are

Tunneling IPv6 over IPv4: A common transition strategy

IPv4 IPsec: Can be used to provide VPN services to IPv6

IPsec transport mode: Typically used

Summary

The key points covered in this chapter are as follows:

• IPsec is a ubiquitous VPN technology that provides confidentiality, data-integrity, authentication, and antireplay services.

• ESP, AH, and IKE perform major functions within IPsec.

• IKEv1 phases 1 and 2 are enhanced by IKEv2.

• IPsec is mandatory and native to IPv6.

References

For additional information, refer to these resources.

Books

Carmouche, J. H. IPSec Virtual Private Network Fundamentals (Cisco Press, 2007).

Naganand, D., and Harkins, D. IPSec: The New Security Standard for the Internet, Intranets, and Virtual Private Networks, Second Edition (Prentice Hall, 2003).

Cisco.com Resources

“Cisco IOS IPsec,” http://www.cisco.com/en/US/products/ps6635/products_ios_protocol_group_home.html

“Export Compliance & Regulatory Affairs: Encryption Control Guidance,” http://www.cisco.com/wwl/export/faq.html

Review Questions

Use the questions here to review what you learned in this chapter. The correct answers are found in the Appendix, “Answers to Chapter Review Questions.”

1. Which of the following is not a security function provided by IPsec?

a. Confidentiality

b. Key management

c. Antireplay

d. Authentication

e. Integrity

2. Which of the following are peer-authentication methods with IPsec? (Choose all that apply.)

a. PSK

b. RSA signatures

c. RSA encrypted nonces

d. HMAC-SHA1

e. HMAC-MD5

3. Which three modes are used by IKE to secure communications?

a. Main mode

b. Basic mode

c. Advanced mode

d. Quick mode

e. Aggressive mode

f. Simple mode

4. Match the Diffie-Hellman group with the size of its keying material.

Groups

a. Group 5

b. Group 2

c. Group 7

d. Group 1

e. Group 16

f. Group 19

Bits

g. 4096

h. 163

i. 1024

j. 1536

k. 256

l. 768

5. Which statement is true regarding how ESP segments are encapsulated in IP packets?

a. In transport mode, security is provided only for the transport layer and below.

b. In tunnel mode, security is provided for the complete original IP packet.

c. In tunnel mode, security is provided only for the transport layer and above.

d. In transport mode, security is provided for the entire IP packet.

6. Match the IPsec component with its category.

a. ESP

b. IKE

c. EDCH

d. EDCSA

1. Key Exchange

2. Authentication

3. Negotiation

4. Confidentiality

7. In IPsec tunnel mode, the original IP address is used to route the packet through the untrusted network. True or false?

a. True

b. False

8. You require DoS protection and mobility for your IPsec phase 1 negotiation. Which protocol would you select?

a. Diffie-Hellman.

b. IKEv2

c. IKEv1

d. AH

9. In IPv6 environments, IPsec is mandatory for all IPv6 communications. True or false?

a. True

b. False

10. You want to prevent filtering IPsec traffic across the path of a VPN. Which three protocols should be allowed in the firewall policy?

a. IP protocol 50

b. TCP 50

c. UDP 51

d. TCP 51

e. UDP 500

f. UDP 4500