Chapter 7. IPSec Virtual Private Networks (VPNs)

Change is life giving, it helps us grow into someone greater than we already are.

—Successories

As connectivity grows and personal mobility increases, the need for networks to adapt and provide services also continues to increase. Users do not understand the security concerns for the remote services that they demand for productively, regardless of location. Users that are traveling to other countries, in airports, customer sites, and so on are demanding the ability to connect to corporate resources to fulfill their jobs. With the increased levels of connectivity from T1s and wireless in airports, to Wi-Fi hot spots, and customers with high-speed connections, those people who are responsible for maintaining networks are faced with some difficult decisions. How should they provide the required IT services to users, regardless of their location, in a secure and reasonable manner?

Technology has evolved and the leading solution for these demands is Internet Protocol Security Protocol (IPSec) encrypted virtual private networks (VPNs). Occasionally, a technology’s name accurately reflects its function, and this is the case with VPNs.

This chapter discusses the use of VPNs, how they function, the encryption provided by IPSec, and how these technologies can ensure that your network’s security is maintained while increasing available services to your customers. Everyone has customers to whom they provide some degree of service, regardless of the field. However, in the case of VPNs, customers can be defined as anyone with the business need to connect securely to the corporate network to access resources. Customers can be mobile users (sales, system engineers), power users going online all the time, executives conducting your company’s affairs, or business partners picking up or dropping off important information. Resources are defined here as any device that is not directly accessible from the Internet; these resources might include e-mail servers, file servers, Citrix servers, or network devices.

Arguably the hottest topic in data security today, virtual private networks (VPNs) are full of promise for businesses seeking to lower cost, increase flexibility and scalability, and ensure the security of their communications.

But what exactly does a VPN do, and how can it impact your business drivers—lowering cost, mitigating risk, and increasing revenue? The popularity of VPN technology is directly related to its potential to bring about significant return on investment (ROI). For businesses paying the often staggering costs of private connections via leased lines or Frame Relay, the costs savings associated with deploying VPNs to replace these costly connections is significant. To understand the value of a VPN to your business, you might want to consider the technologies that VPNs most often replace:

• Site-to-site VPNs can take the place of expensive wide-area network (WAN) telco circuits by replacing private line services with VPNs that use the Internet instead.

• Remote access VPNs can eliminate or dramatically reduce long-distance dialup charges for connecting a remote sales force or small offices.

If your organization is making significant recurring investments in either WAN telco circuits or long-distance remote access dialup charges, a VPN can provide an alternative approach with a big payoff in cost savings and flexibility.

Before entering into a technical overview of the components and possibilities involved in deploying a VPN, it is important to firmly understand the gist of the VPN concept. Analogies work well because they introduce people with vastly different levels of knowledge and experience to a complex subject.

Analogy: VPNs Connect IsLANds Securely

Your network (LAN) is an island of sanity, order, and user services in an unpredictable ocean known as the Internet. You know thousands of other islands exist within this ocean; when you want to travel from island to island, you would hop on a ferry and check out that website you had your eye on.

Now, you are on this ferry (TCP/IP) traveling over the ocean (Internet) to reach something on an island (LAN) that is going to provide you with some sort of service (website). This makes perfect sense, right? Now, how many other people do you see on that ferry—perhaps a few, or perhaps many thousands? The potential problem is that you have no security or privacy traveling from island to island; other people can see everything you see. Now, if you were reading the latest news on http://www.foxnews.com, who cares if you do not have privacy? However, if you were going to your company’s island to check on something, this lack of privacy can have serious ramifications.

Because you are traveling on the worldwide ocean that is the Internet, you have no control over the wires, fiber, routers, or switches that make up the Internet. Nor do you get any guarantees of any sort. In other words, you might be able to reach some website or other server, but there are no guarantees. Remember, connecting to the Internet is a privilege and not a right! Having no control of the Internet means that you are susceptible to security issues, and this becomes especially true if you want to connect two private networks using a public resource such as the Internet.

As the person in charge of connecting your island to another, you are directed to connect your island with a new one that was just purchased. Your island decides to build a bridge to this other island so there is an easier, more secure, and direct way for people to travel between the two. It is expensive to build and maintain this bridge, even though the island you are connecting with is close. But the need for a reliable, secure path is so great that you do it anyway.

This situation is a lot like having a private wide-area network (WAN). The bridges (private lines) are separate from the ocean (Internet), yet they can connect the islands (LANs). Many companies have chosen this route because the need for security and reliability drives the connection from their remote offices to their main office.

Your island would like to connect to a second island that is much farther away, but you decide that the cost to build a bridge are simply to high to justify. You quickly learned that, if the offices are far apart, the cost could be prohibitively high, just like trying to build a bridge that spans a great distance. However, the need is still there.

Are you wondering when VPNs are going to fit into this analogy? You have established that you need increased security, and the first option was to build a bridge; however, that is too expensive. You could give everyone who needs the ability to travel between islands privately and securely a submarine. A submarine is a perfect analogy for a VPN because, like a submarine, VPNs have the following amazing properties:

• They can be very fast.

• They are easy to take with you.

• They can hide you from others.

• Additional cost is minimal after they are first deployed.

• They protect you when you are traveling.

• VPN-aware PDAs are the latest entry into the VPN market.

• The Cisco VoIP SoftPhone application also works well over a VPN, turning your PC into a secure telephone.

It might not be easy to take a submarine with you; however, I am sure you understand this analogy. There are several different ways to implement VPNs, and the following sections examine the three types of VPNs. Another good analogy would be the concept of the Stargate portals. You must get the symbols right on both sides (the SA for VPN), and you must have a Stargate on the other side that is “on” for the hyperspace tunnel to form (the VPN tunnel)....

VPN Overview

A virtual private network (VPN) is an encrypted network connection that uses a secure tunnel between endpoints via the Internet or other network, such as a WAN. In a VPN, dialup connections to remote users and leased-line or Frame Relay connections to remote sites are replaced by local connections to an Internet service provider (ISP) or other service provider’s point of presence (POP). The increasing prevalence of Internet broadband connections to small remote offices and homes makes the use of cheaper access to the Internet attractive. As discussed, after the initial investment in VPNs, the cost to add more sites or users is minimal.

VPNs allow each remote user of your network to communicate in a secure and reliable manner using the Internet as the medium to connect to your private LAN. A VPN can grow to accommodate more users and different locations much easier than a leased line. In fact, scalability is a major advantage that VPNs have over typical leased lines. Unlike leased lines, where the cost increases in proportion to the distances involved, the geographic locations of each office matter little in the creation of a VPN.

A VPN allows a private intranet to be securely extended through IPSec encryption across the Internet or other network service, facilitating secure e-commerce and extranet connections with mobile employees, business partners, suppliers and customers. There are three main types of VPNs:

• Remote Access VPNs—Allows individual dialup users to securely connect to a central site across the Internet or other public network service. This type of VPN is a user-to-LAN connection that allows employees who need to connect to the corporate LAN from the field. Their systems use special VPN client software that enables a secure link between themselves and the corporate LAN. Typically, a corporation that wants to set up a large remote access VPN provides some form of Internet dialup account to their users using an ISP. The telecommuters can then dial a toll-free number to reach the Internet and use their VPN client software to access the corporate network. A good example of a company that needs a remote access VPN would be a large firm with hundreds of salespeople in the field. Remote access VPNs are sometimes referred to as soft (as in software-based) VPNs, virtual private dialup networks (VPDN), or dial VPNs. Users pay a low “fixed cost” to a local ISP using a local call and therefore they incur no long-distance fees and do not have to establish a long-distance call directly to the corporate office. The user can then use the local ISP connection to establish a VPN tunnel over the Internet. CFOs prefer small, fixed costs to increasing long-distance costs.

• Site-to-site VPNs—Used to extend a company’s existing LAN to other buildings and sites through the use of dedicated equipment, so that remote employees at these locations can utilize the same network services. These types of VPNs are considered actively connected at all times. Site-to-site VPNs are sometimes referred to as hard (as in hardware-based) VPNs, intranet, or LAN-to-LAN VPNs.

• Extranet VPNs—Allows secure connections with business partners, suppliers, and customers for the purpose of e-commerce. Extranet VPNs are an extension of intranet VPNs with the addition of firewalls to protect the internal network. A good example would be companies that work closely with suppliers and partners to achieve common goals such as supply and demand relationships—for example, when one company has a demand for supplies and the supplier fulfills the demand based upon the company’s needs. Working across an extranet, these two companies can share information more quickly.

All these VPNs aim to provide the reliability, performance, quality of service, and security of traditional WAN environments using lower cost and more flexible ISP or other service-provider connections. Figure 7-1 illustrates the three types of VPNs.

Figure 7-1. Types of VPNs

In Figure 7-1, all the VPNs are utilizing the Internet. VPN technology can also be used within your network to provide an additional layer of security to control access to sensitive information, systems, or resources. For example, VPN technology can be used to limit access to financial systems to certain users or to ensure that sensitive or confidential information is sent in a secure way. In this scenario, VPNs can encrypt and further secure traffic to sensitive systems. The following section discusses the placement of VPNs and the specific associated benefits.

VPN Benefits and Goals

A well-designed VPN can greatly benefit any company. Some of the benefits of implementing a VPN in your network include the following:

• Before the advent of VPN technologies, employees in remote locations would have to dial long-distance telephone numbers to reach their company’s network. You want to reduce telecom costs as dedicated and long-distance dialup connections are replaced with local connections to the Internet through which users use a VPN client. Depending on the number of employees in the field, this alone can be a huge cost savings. For many smaller companies with limited financial breathing room, VPN solution providers can be a practical solution.

• You want to increase the productivity of your users by enabling them to securely access network resources regardless of their geographic location.

• You want to reduce the operational costs associated with dedicated WAN connections by replacing them with direct Internet connections such as business class broadband, through which remote sites will connect via a site-to-site VPN.

• You want to simplify your network’s topology by adding VPNs strategically throughout your network.

• Your bandwidth needs are modest as sites need connectivity into your network. By using VPNs, you will gain a faster return on investment (ROI) than a traditional WAN solution.

• You want greater flexibility in deploying mobile computing, telecommuting, and branch office networking, easier e-commerce and extranet connections with business partners, suppliers and customers’ external Internet access, and internal intranet and extranet access can be provided using a single secure connection.

• You want to reduce office costs by having users work from home three days a week. Home users typically have higher production and less stress.

Before implementing a VPN, you should spend a considerable amount of time contemplating what you want to accomplish with your VPN. During this exercise, before choosing a solution provider or hardware and software, you should consider which features are most important. Security, which is mentioned later, is one of the most important features of your VPN.

VPN Implementation Strategies

VPN implementation strategies are extremely varied because every vendor these days has a “VPN solution” for you! Some of the solutions are what they claim to be, and others have raised concerns among the security community, as discussed in Chapter 6, “Router Security.” Because there is no widely accepted standard for implementing a VPN, many companies have developed turnkey solutions on their own. This section looks at some of the different potential components that are available from Cisco, and how single function devices such as firewalls can be used to fulfill a VPN role:

• Firewalls—If you did not have a firewall in place before reading Chapter 5, “Firewalls,” you probably do now. Firewalls are crucial to the security of your network. Today, all Cisco firewalls support the combining of VPNs with stateful packet inspection (SPI). Solutions range from standards-based site-to-site VPNs leveraging the Internet Key Exchange (IKE) and IP security (IPSec) VPN standards. Cisco PIX firewalls encrypt data using 56-bit Data Encryption Standard (DES), 168-bit Triple DES (3DES), or up to 256-bit Advanced Encryption Standard (AES) encryption. An amazing piece of technology, the Cisco PIX Firewall combines dynamic Network Address Translation, proxy server packet filtration, firewall and VPN termination capabilities into a single piece of hardware. Instead of using Cisco IOS Software, this device has a highly streamlined OS that trades the capability to handle a variety of protocols for extreme robustness and performance by focusing on IP.

• VPN-capable routers—Cisco routers can be upgraded to have the ability to use VPNs. These upgrades come in some form of the following, depending on the router model in question: IOS, memory, or dedicated VPN hardware. You can gain some unique features with the provision of scalability, routing, security, and quality of service (QoS). Based on Cisco IOS Software, there is a router suitable for every situation, from small office/home office (SOHO) access through central-site VPN aggregation, to large-scale enterprise needs.

• VPN Concentrator—Incorporating the most advanced encryption and authentication techniques available, Cisco VPN Concentrators are built specifically for creating remote access user VPNs, which provide high availability, high performance, and scalability, and include components called scalable encryption processing (SEP) modules, which enable network engineers to easily increase capacity and throughput. VPN Concentrators are built to handle the requirements of VPNs and are available in models suitable for everything from small businesses with up to 100 remote-access users, to large organizations with up to 10,000 simultaneous remote users.

• Client Software—Simple to deploy and operate, the Cisco VPN Client establishes secure, end-to-end encrypted tunnels to the VPN devices listed here. This thin design, IPSec-compliant software can be preconfigured for mass deployments, and the initial logons require little user intervention. The client software is available for the following operating systems: Windows 95, 98, Me, NT 4.0, 2000, XP, Linux (Intel), Solaris (UltraSparc-32bit), and MAC OS X 10.x.

Depending on the type of VPN (remote access or site-to-site), you must use specific hardware components to build your VPN. However, you should also consider the following:

• Manageability—Manageability of a VPN concerns the amount of effort needed to successfully maintain the established network connectivity. Specifically, PC Magazine rates manageability by the “ease-of-use factors for remote and local management options, including whether the device provides a browser-based interface or command line access” (PC Magazine, 2002).

• Reliability—Obviously, if the VPN software or hardware is unavailable when you need it, you are losing productivity and probably money. When choosing a solution, you should request “up-time” statistics for comparison.

• Scalability—As a company’s business grows, oftentimes, so does its IT requirements. To grow your VPN infrastructure quickly and cost-effectively, it is important to choose a solution that has scalability in mind. The last thing an IT manager wants to do is start from scratch and replace his VPN infrastructure because of a bottleneck in its growth potential.

When selecting the right device to provide VPN services to your network, you must be aware of the limitations. For example, a router’s IOS can terminate VPNs, but that is a manual process to configure and it requires a deeper understanding than if you were to use a PIX Firewall with its VPN Configuration Wizard available in the GUI. There is also the Cisco VPN Concentrator, which offsets the PIX or IOS as the powerful GUI that eases the management of many different VPN policies. The Cisco VPN Concentrator offers intuitive instructions on setting up these different policies and groups, thus allowing many different users into a network with different enforcement groups associated to that group. I typically bring up the concentrator when the customer has limited staffing and needs many different VPN policy needs. The IOS with PIX is a little more difficult to set up and manage for this particular need. Do not forget scalability, either.

Split Tunneling

Many VPN users are already behind firewalls, and they need to access resources only through a VPN. Traditional VPNs do not allow users to also access network resources on their local segment while they are connected to their corporate VPN at the same time. This becomes an issue when, for example, these users must access a system via a VPN and print to a local network printer. To correct this potential problem, a feature has been introduced known as split tunneling.

Split tunneling occurs when a remote VPN user or site is allowed to access a public network (the Internet) at the same time that he accesses the private VPN, without placing the public network traffic inside the tunnel first. This is not always the best feature to enable, however, because it could allow an attacker to compromise a computer that is connected to two networks. Figure 7-2 illustrates an overview of how split tunneling works.

Figure 7-2. Split Tunneling Overview

Overview of IPSec VPNs

IPSec has become the de facto standard for creating VPNs in the networking industry. Several vendors have implemented it and, because the Internet Engineering Task Force (IETF) has defined IPSec is defined in an RFC, interoperability between vendors makes IPSec the best option for building VPNs. IPSec offers a standard means of establishing authentication and encryption services between peers. For purposes of this discussion, IPSec peers are devices that form each end of a VPN tunnel. IPSec acts at the network layer of the OSI reference model, protecting and authenticating IP packets between participating IPSec devices (“peers”), such as Cisco routers or firewalls. IPSec provides the following network security services:

• Data confidentiality—The IPSec sender can encrypt packets before transmitting them across a network. If a hacker cannot read the data, it is of no use to him.

• Data integrity—The IPSec receiving endpoint authenticates all packets sent by the IPSec sender to ensure that the data has not been altered during transmission.

• Data origin authentication—The IPSec receiver can authenticate the source of the IPSec packets that were sent. This service depends on the data integrity service.

• Anti-replay—The IPSec receiver can detect and reject replayed packets.

IPSec protects sensitive data that travels across unprotected networks, and IPSec security services are provided at the network layer; therefore, you do not have to configure individual workstations, PCs, or applications. This benefit can provide a great cost savings. Rather than providing the security services that you do not need to deploy and coordinate security on a per-application, per-computer basis, you can simply change the network infrastructure to provide the needed security services. This support allows IPSec solutions to scale to medium-sized, large-sized, and growing networks, where a secure connection between many devices is required.

IPSec provides enhanced security features, such as better encryption algorithms and more comprehensive authentication. Corporate networks connected to the Internet can enable flexible and secure VPN access with IPSec. With IPSec technology, customers can now build VPNs over the Internet with the security of encryption protection against wire tapping, eavesdropping, or other attacks that intrude on private communications.

IPSec provides authentication and encryption services to protect unauthorized viewing or modification of data within your network or as it is transferred over an unprotected network, such as the public Internet. IPSec can encrypt data between various devices, such as

• Router to router

• Firewall to router

• Firewall to firewall

• User to router

• User to firewall

• User to VPN concentrator

• User to server

IPSec is a framework of open standards defined by the IETF. IPSec provides security for transmission of sensitive information over unprotected networks, such as the Internet. Figure 7-3 shows the three most common types of VPNs.

Figure 7-3. VPN Connectivity Overview

Authentication and Data Integrity

To establish trust, authentication verifies the identity of the two VPN endpoints and the users sending traffic through the VPN. An endpoint could be a VPN client, VPN Concentrator, firewall, or router. Authentication is a process of IPSec that occurs after data encryption and before decryption on the receiving end. It is a necessary function within IPSec to ensure that both the sending and receiving parties are who they claim to be. With IPSec, each peer must be manually configured with a preshared key (usually agreed upon out of band) and a static list of valid peers, thereby creating a possibly large table within the router, which would take up memory resources.

Data integrity is another function within IPSec. Integrity means that the packet that the receiving party received has not been altered during transmission. This is achieved via the use of a one-way hash algorithm. A one-way hash is the equivalent of an encrypted checksum. After the sending party encrypts and authenticates a packet, a one-way hash is run on the value of the entire packet. A hash is interesting in that its result will always be a fixed size, regardless of the input. This is another security mechanism so hackers cannot know the input field size. The oneway hash creates an encrypted field that is appended to the message. On the receiving end, the one-way hash value is pulled from the packet, and the receiving end runs its own one-way hash. Because the hash is run on variables within the packet such as time sent, number of bytes, and so on, both ends’ hash value must be the same—meaning that the packet has not been tampered with. If the values are different, the packet is discarded, and IPSec renegotiates its security parameters.

Tunneling Data

Tunneling is what VPNs rely on to create a private network over the Internet. Basically, this is the process of taking an entire packet of data and encapsulating it within another packet before sending it over a network. The network must understand the outer packet’s protocol to enter and exit the network. Tunneling requires three different protocols to work:

• Passenger protocol—The original data packet, usually IP, which is to be encrypted into the VPN. If you so desire, other protocols such as IPX or NetBEUI could be included.

• Encapsulating protocol—The protocol (GRE, IPSec, L2F, PPTP, L2TP) that is wrapped around the original data (that is, encapsulated). IPSec is the de facto standard that is used as the encapsulating protocol at this stage, and it allows for the entire passenger packet to be encrypted and protected. IPSec must be supported at both tunnel interfaces for proper operation.

• Carrier protocol—The protocol the network uses and over which the information travels. The original packet (passenger protocol) is encapsulated inside the encapsulating protocol, which is then put inside the carrier protocol’s header (usually IP) for transmission over the public network.

Tunneling works well with VPNs because you can use protocols that are not supported on the Internet inside an IP packet, and it can still be sent safely. At the beginning of a VPN tunneled transmission, a data packet from the source LAN is wrapped or encapsulated with new header information that allows intermediary networks to recognize and deliver it. After this is done and the transmission is complete, the tunneling protocol “header” is stripped off, and the original packet is transferred to the destination LAN for delivery.

Although tunneling allows data to be carried over third-party networks, tunneling alone does not ensure privacy. To secure a tunneled transmission against any interception and tampering, all traffic over the VPN is encrypted. In addition, VPNs typically include additional features, such as firewalls at the perimeters.

In site-to-site VPNs, the encapsulating protocol is usually IPSec or generic routing encapsulation (GRE). GRE includes information about what type of packet you are encapsulating and about the connection between the client and server. The difference depends on the level of security needed for the connection, with IPSec being more secure and GRE having greater functionality. IPSec can tunnel and encrypt IP packets, whereas GRE can tunnel IP and non-IP packets. When you need to send non-IP packets (such as IPX) over the tunnel, IPSec and GRE should be used together.

Encryption Modes

IPSec has two encryption modes: tunnel and transport. Each mode differs in its application and in the amount of overhead added to the passenger packet. These different modes of operation are summarized briefly in that tunnel encrypts the packet header and the payload of each packet, while transport encrypts only the payload.

Tunnel Mode

This is the normal way in which IPSec is implemented between two PIX Firewalls (or other security gateways) that are connected over an untrusted network, such as the public Internet. All discussions involving IPSec will be on the tunnel mode. Tunnel mode encapsulates and protects an entire IP packet. Because it encapsulates or hides the packets to be successfully forwarded, the encrypting routers themselves own the IP addresses that are used in these new headers. Tunnel mode can be employed with either or both ESP and AH. Using tunnel mode results in additional packet expansion of approximately 20 bytes associated IP header, a new IP header must be added for the packet with the new IP header, as shown in Figure 7-4.

Figure 7-4. Tunnel Mode

Transport Mode

This method of implementing IPSec is typically done with L2TP to allow the authentication of remote Windows 2000 VPN clients. Chapter 5 already covered this concept, so this chapter focuses on IPSec and tunnel mode. In tunnel mode, IPSec encrypts the entire packet and writes a new IP header into the packet, which masks the original source and destination information. Tunnel mode is inherently more secure than transport mode (because of the fact that the entire original packet is encrypted, not just the payload as in transport mode), as shown in Figure 7-5.

Figure 7-5. Transport Mode

IPSec Protocols

IPSec uses three complementary protocols that, when used together, form a cohesive and secure standards-based framework that is ideally suited for VPNs. Following are the three protocols described in the IPSec standards:

• Internet Security Association Key Management Protocol (ISAKMP)—Describes the phase of negotiating the IPSec connection to establish the VPN; Oakley defines the method to establish an authenticated key exchange. This method can take various modes of operation and can also derive keying material via algorithms such as Diffie-Hellman. Within ISAKMP is Internet Key Exchange (IKE) that provides a framework for negotiating security parameters (for example, SA lifetime, encryption type, and so on) and establishing the veracity of the keys.

• Encapsulated Security Protocol (ESP)—Provides data confidentiality and protection with optional authentication and replay-detection services. ESP completely encapsulates user data. ESP can be used either by itself or in conjunction with AH. ESP runs using the TCP protocol on ports 50 and 51 and is documented in RFC 2406.

• Authentication Header (AH)—Provides authentication and anti-replay services (optional). AH provides services to limited portions of the IP header and extended header, but does not provide for data encryption by applying a one-way hash to create a message digest of the packet. AH is embedded in the data to be protected (a full IP datagram, for example). AH can be used either by itself or with Encryption Service Payload (ESP). (Refer to RFC 2402.) This protocol has largely been superseded by ESP and is considered deprecated.

Security Associations

Security associations (SAs) establish trust between two devices in a peer-to-peer relationship and enable VPN endpoints to agree on a set of transmission rules by negotiating policies with a potential peer. Consider a security association like a contract that negotiates and then sets various parameters with regard to the connection parameters.

A security association is identified through an IP address, a security protocol identifier, and a unique security parameter index (SPI) value. The SPI value is a 32-bit number embedded in packet headers. The two types of security associations are

• Internet Key Exchange (IKE)—Provides negotiation, peer authentication, key management, and key exchange. As a bidirectional protocol, IKE provides a secure communication channel between two devices that negotiates an encryption algorithm, a hash algorithm, an authentication method, and any relevant group information. It uses key exchange based on Diffie-Hellman algorithms, and network administrators can closely tie IKE with policy management systems. To prevent a man-in-the-middle attack—when an attacker sniffs packets from the network, modifies them, and inserts them back into the network—a Diffie-Hellman enhancement called Station-to-Station (STS) protocol allows two devices in the Diffie-Hellman exchange to authenticate each other using digital signatures and public-key certificates.

• IPSec Security Association (IPSec SA)—IPSec SA is unidirectional and thus requires that separate IPSec SAs is established in each direction. IPSec SA is a two-phase, three-modes procedure. In Phase 1, two modes can be used: main mode and aggressive mode. In Phase 2, the only available mode is called quick mode. The end user has no control over which mode is chosen; rather, the selection is automatic and depends on the configuration parameters set up by both peers.

Both IKE and IPSec use SAs, although SAs are independent of one another. IPSec SAs are unidirectional and are unique in each security protocol. The security associations define which protocols and algorithms should be applied to sensitive packets and specify the keying material to be used by the two peers. SAs are unidirectional and are established separately for different security protocols (AH and/or ESP). IPSec SAs can be established in two ways:

• Manual SAs with preshared keys—The use of manual IPSec SAs requires a prior agreement between administrators of the PIX Firewall and the IPSec peer. There is no negotiation of SAs, so the configuration information in both systems should be the same for IPSec to process traffic successfully. Manual is easy to configure; however, it is difficult to change preshared keys because the tunnel fails when you do, and the trouble is that preshared keys are usually never changed.

• IKE-established SAs—When IKE is used to establish IPSec SAs, the peers can negotiate the settings they will use for the new security associations. This means that you can specify lists (such as lists of acceptable transforms) within the crypto map entry.

Internet Key Exchange (IKE)

This section describes the Internet Key Exchange (IKE) protocol and how it works with IPSec to make VPNs more scalable. IKE is a hybrid protocol that uses part of Oakley and part of another protocol suite called Secure Key Exchange Mechanism (SKEME) inside the Internet Security Association and Key Management Protocol (ISAKMP) framework. You can see in Figure 7-6 that IKE is a true hybrid protocol.

Figure 7-6. IKE Composition

IKE establishes a shared security policy and is authenticated keys for services (such as IPSec) that require keys. Before any IPSec traffic can be passed, each router/firewall/host must be able to verify its peer’s identity. This can be done by manually entering preshared keys into both hosts, by a Certification Authority (CA) service, or secure DNS (DNSSec). IKE is the protocol formerly known as ISAKMP/Oakley, and it is defined in RFC 2409.

IKE is a protocol that IPSec uses for completion of Phase 1. IKE negotiates and assigns security associations (SAs) for each IPSec peer, which provides a secure channel for the negotiation of the IPSec SAs in Phase 2. IKE provides the following benefits:

• Eliminates the need to manually specify all the IPSec security parameters at both peers

• Allows you to specify a lifetime for the IPSec SAs

• Allows encryption keys to change during IPSec sessions

• Allows IPSec to provide anti-replay services

• Enables CA support for a manageable, scalable IPSec implementation

• Allows dynamic authentication of peers

IKE negotiations must be protected, so each IKE negotiation begins by the peer agreeing on a common (shared) IKE policy. This policy states the security parameters that will be used to protect subsequent IKE negotiations. After the two peers agree on a policy, a security association established at each peer identifies the policy’s security parameters, and these SAs apply to all subsequent IKE traffic during the negotiation.

ISAKMP Overview

Internet Security Association and Key Management Protocol (ISAKMP) is a framework that defines the mechanics of implementing a key exchange protocol and negotiation of a security policy. ISAKMP is used for secure exchanges of both SA parameters and private keys between peers in an IPSec environment, as well as key creation and management.

ISAKMP provides for several methods of key management and provides secure transit of IPSec parameters between peers. It accomplishes this by using similar algorithms used by IPSec for the actual encryption of the data payload. Like IPSec, ISAKMP is not a protocol, but simply an interface to manage various ways of dynamic key exchange. ISAKMP defines various methods—such as digital signatures, certificates, and one-way hash algorithms—to ensure that negotiation of SAs between peers is handled securely.

Currently, the only supported protocol in ISAKMP is the Internet Key Exchange (IKE) protocol. When IKE is actively employed in the encryption process, many features become available to the IPSec communication process. Using public-key cryptography, IKE negotiates security parameters and key exchanges before the IPSec processing ever begins.

IPSec Operational Overview

IPSec’s main task is to allow the exchange of private information over an insecure connection by negotiating the connection and providing the keys in a secure manner. IPSec uses encryption to protect information from interception or eavesdropping. However, to use encryption efficiently, both parties should share a secret key (password) that is used for both encrypting and decrypting the information as it enters and exits the VPN tunnel. IPSec uses IKE to establish the secure link so the VPN forms and data connects. At a very high level, the sequence of events for an IPSec transaction is as follows:

1. One of the IPSec peers receives or generates interesting traffic on an interface that has been configured to initiate an IPSec tunnel for this interesting traffic.
2. Main mode or aggressive mode negotiation using IKE results in the creation of an IKE security association (SA) between two IPSec peers.
3. Quick mode negotiation using IKE results in the creation of two IPSec SAs between two IPSec peers.
4. Data starts passing over an encrypted tunnel using the ESP or AH encapsulation techniques.

These four seemingly simple steps require some additional examination. IPSec operates in two major phases to allow the confidential exchange of a shared secret key, as described in the sections that follow.

IKE Phase 1

IKE Phase 1 handles the negotiation of security parameters required to establish a secure channel between two IPSec peers. Phase 1 is generally implemented through the IKE protocol and is primarily concerned with establishing the protection suite for IKE messages. The sequence of events of IKE Phase 1 is as follows:

1. Phase 1 is the creation of the ISAKMP SA, where peers negotiate and agree upon parameters for IPSec SAs to follow. After Phase 1 is complete and a secure channel is established between peers, IKE moves into Phase 2.
2. If the remote IPSec peer cannot do IKE, you can use manual configuration with preshared keys to complete Phase 1.

Figure 7-7 shows the negotiation of the Phase 1 parameters through the use of SA.

Figure 7-7. IKE Phase 1 Operation

IKE’s Phase I operation has two modes of operation: aggressive and main mode. Aggressive mode eliminates several steps in the authentication of IKE, reducing it to just three steps, whereas main mode uses the full four steps to authenticate. Although it’s faster, aggressive mode is considered less secure than main mode, for obvious reasons. Cisco devices use main mode by default, but they will respond for peers using aggressive mode.

IKE Phase 2

IKE Phase 2 advances the security of the connection by using the secure tunnel established in IKE Phase 1 to exchange the additional security parameters required to actually transmit user data (see Figure 7-8).

Figure 7-8. IKE Phase 2 Operation

In Phase 2, IKE negotiates SAs on behalf of IPSec, according to parameters configured in IPSec. The ISAKMP SA created in Phase 1 protects these exchanges.

The secure tunnels used in both phases of IPSec are based on security associations (SAs) used at each IPSec endpoint. SAs describe the security parameters, such as the type of authentication and encryption that both end points agree to use.

Diffie-Hellman Algorithm

The Diffie-Hellman algorithm was the first public-key algorithm, and is still considered one of the best. IKE uses public-key cryptography to negotiate security parameters and protect key exchanges. Specifically, the Diffie-Hellman algorithm is used in the IKE negotiations to allow the two peers to agree on a shared secret by generating the key for use. This is why you will see that the Diffie-Hellman algorithm is used several times throughout the process.

In general, here is how the algorithm works: Each peer contains a private key. The Diffie-Hellman algorithm takes that private key and generates a public key. The public key is a product of the private key, but is such that the private key cannot be deduced by knowing the public key. The peers then exchange public keys, as shown in Figure 7-9.

Figure 7-9. Diffie-Hellman Key Exchange

If peer A wants to pass encrypted traffic to peer B, peer A encrypts the traffic going to peer B with peer B’s public key.

Peer B then uses its own private key to decrypt the message because its public key is derived from its private key. This ensures that only peer B can decrypt the message because only peer B knows its own private key.

This method allows for a secure communications channel to be established (ISAKMP SA) so that subsequent IPSec SAs can securely exchange key information in privacy without having to use a public-key algorithm to exchange their own keys every time encrypted traffic is passed. Figure 7-10 shows the various steps in ISAKMP Phase 1 and 2 negotiations.

Figure 7-10. VPN Connection Establishment

Figure 7-10 illustrates that traffic is already encrypted before the end of IKE Phase 1. This provides for a secure exchange of the IPSec proposals and keys performed on behalf of IPSec in IKE Phase 2.

In addition to providing a secure mechanism for key exchange and managing IPSec SAs, ISAKMP also provides several other important functions. ISAKMP can be configured to set IPSec SA Lifetimes, which allows for more control over how often keys are exchanged. It also allows for keys to change during communication without removing and recreating the IPSec SAs. With standalone IPSec, if keys are to change during communication, existing SAs are “torn-down” and rebuilt with the new keys. Because ISAKMP negotiates SAs for IPSec and protects them with its own SA, keys can be changed on-the-fly without recreating SA negotiations. This provides a substantial advantage over IPSec alone. ISAKMP also allows for dynamic authentication of peers and data integrity checks via the use of one-way hash algorithms.

Router Configuration as VPN Peer

I wanted to include one of the ways to configure a router with the ability to be part of a site-to-site VPN. I felt this particular configuration was important based on the fact that Cisco routers make up 80 percent of the routers in operation today. Therefore, it seemed that many networks could have their security greatly increased by using the router to terminate VPNs.

Configuring ISAKMP

IKE exists only to establish SAs for IPSec, but before it can do this, it must negotiate an SA (an ISAKMP SA) relationship with the peer. Because IKE negotiates its own policy, it is possible to configure multiple policy statements with different configuration statements, and then let the two hosts come to an agreement. ISAKMP negotiates the following:

• Encryption algorithm—Used to protect user data transmitted between two IPSec peers (DES or 3DES).

• Hashing algorithm: MD5 or SHA—This selection specifies the hash algorithm used to ensure data integrity. The default is SHA-1. MD5 has a smaller digest and is considered slightly faster than SHA-1.

• Authentication—RSA signatures, RSA encrypted nonces (random numbers), or preshared keys. This selection specifies the method of authentication that is used to establish the identity of each IPSec peer. Preshared keys do not scale well with a growing network, but they are easier to set up in a small network.

• Lifetime of the SA (in seconds)—The default is 86,400 seconds or 24 hours. As a general rule, a shorter lifetime (up to a point) provides more secure IKE negotiations. However, with longer lifetimes, future IPSec security associations can be set up more quickly. However, as with many of the characteristics used in the VPN creation, the VPN tunnel activates and functions if the values do not match.

There is an implicit trade-off between security and performance when you choose a specific value for each parameter. The level of security provided by the default values is adequate for most organization’s security requirements. If you are inter-operating with a peer that supports only one of the values for a parameter, your choice is limited to the other peer’s supported value.

When the IKE negotiation begins, the peer that initiates the negotiation sends all its policies to the remote peer, which tries to find a match. The remote peer checks its policies in order of priority (highest priority first) until a match is found.

A match is made when both policies from the two peers contain the same encryption, hash, authentication, and Diffie-Hellman parameter values, and when the remote peer’s policy specifies a lifetime less than or equal to the lifetime in the policy being compared. If the lifetimes are not identical, the shorter lifetime (from the remote peer’s policy) is used.

If no acceptable match is found, IKE refuses negotiation and IPSec is not established. If a match is found, IKE completes negotiation, and IPSec security associations are created. Currently, there are two methods of configuring ISAKMP:

• Use preshared keys, which have the advantage of being simple to configure.

• Use a centralized Certificate Authority (CA), which is a third-party entity that is responsible for issuing and revoking certificates. Each device that has its own certificate and public key of the CA can authenticate every other device within a given CA’s domain. This solution has the advantage of being scalable throughout a large enterprise network.

The following section discusses the use of preshared keys, which is by far the most common method of configuring ISAKMP.

Preshared Keys

If you use the IKE authentication method of preshared keys, you are setting the keys, or in other words, sharing them with the other peer with whom you plan on creating a VPN by manually configuring these keys on the device and its peer(s). You can specify the same key to share with multiple peers, but it is more secure to specify different keys to share between different pairs of peers. To configure a preshared key on the PIX Firewall, perform the following steps. Although configuring IKE is simple and you do not use a CA, it does not scale well. To configure IKE, you must

Step 1 Configure ISAKMP policy options.

Step 2 Configure ISAKMP key.

Configuring the ISAKMP Protection Suite

The following command creates the ISAKMP policy object. It is possible to have multiple policies, but there is only one in this example:

INRGI(config)#crypto isakmp policy 1
INRGI(config-isakmp)#

With the following group command, you can declare what size modulus to use for Diffie-Hellman calculation:

INRGI(config-isakmp)#group 2

Group 1 is 768 bits long, and group 2 is 1024 bits long. Why would you use one over the other? First of all, not all vendors support group 2. Secondly, group 2 is also significantly more CPU-intensive than group one; therefore, you would not want to use group 2 on low-end routers like the Cisco 2500 series or less. On the other hand, group 2 is more secure than group 1.

Because security is of primary concern, group 2 is used here (make sure the peer is also configured to use group 2). The default is group 1. If you select the default properties, the group 1 lines do not show up when you show the configuration command.

MD5 is the hashing algorithm as configured in the following command. Although implementing SHA and MD5 are both mandatory, not all peers can be configured to negotiate one or the other:

INRGI(config-isakmp)#hash md5

The following command shows the security association’s lifetime—in this case, 500 seconds. If you do not set a lifetime, it defaults to 86,400 seconds, or one day. When the lifetime timer fires, the SA is renegotiated as a security measure:

INRGI(config-isakmp)#lifetime 500

The authentication pre-share command tells IKE what key to use:

INRGI(config-isakmp)#authentication pre-share

Two options for the authentication command besides the pre-share are

• rsa-encr—Configures RSA-encrypted nonces

• rsa-sig—Configures RSA signature

The rsa-encr and the rsa-sig options are addressed in the section, “Using a CA.” For now, remember that rsa-sig is the default.

Configuring the ISAKMP Key

The following commands tell IKE what key to use. Remember that the peer, 192.168.10.38 in this case, must have the same key “Slurpee-Machine” in its configuration. I use this particular key because I am configuring a VPN to my good friend Cary’s office and he is addicted to these cold delights:

INRGI(config-isakmp)#exit

INRGI(config)#crypto isakmp key Slurpee-Machine address 192.168.10.38

At this point, you are finished with IKE configuration. For the record, the following lines are the peer’s IKE configuration:

Configuring IPSec

Whether you use preshared keys or configure a CA, you still have to setup IPSec after you set up IKE. Regardless of which IKE method you use, the IPSec configuration steps are the same. To configure IPSec, you need to

Step 1 Create the extended ACL.

Step 2 Create the IPSec transforms.

Step 3 Create the crypto map.

Step 4 Apply the crypto map to an interface.

Step 1: Create the Extended ACL

The following command is a simple ACL that allows the routers to talk to one another (a Telnet from one router to the next, for example):

A more realistic ACL looks like the following command:

This command is an ordinary extended ACL, where 192.168.3.0 is a subnet behind the router in question and 10.3.2.0 is a subnet somewhere behind the peer router. Remember that permit means encrypt, and deny means do not encrypt.

Step 2: Create the IPSec Transforms

A transform describes a security protocol (AH or ESP) with its corresponding algorithms. For example, ESP with the DES cipher algorithm and HMAC-SHA for authentication. A transform set represents a certain combination of security protocols and algorithms. During the IPSec security association negotiation, the peers agree to use a particular transform set for protecting a particular data flow. You can specify multiple transform sets, and then specify one or more of these transform sets in a crypto map entry. The transform set defined in the crypto map entry is used in the IPSec security association negotiation to protect the data flows specified by that crypto map entry’s access list. During IPSec security association negotiations with IKE, the peers search for a transform set that is the same at both peers. When such a transform set is found, it is selected and applied to the protected traffic as part of both peers’ IPSec security associations. With manually established security associations, there is no negotiation with the peer, so both sides must specify the same transform set.

Create three transform sets, as done in the following command lines:

The first set uses only ESP, the second set uses AH combined with ESP, and the last set uses only AH. During IPSec SA negotiation, all three are offered to the peer, which chooses one. Also, use the default tunnel mode for all three transform sets. Transport mode can be used only when the crypto endpoints are also the communication’s endpoints. The mode transport command under the transform-set configuration can specify the transport mode. Tunnel mode is used primarily for the VPN scenario.

Also note that esp-rfc1829 and ah-rfc1828 are based on the original RFCs for this technology and are obsolete transforms that are included for backwards compatibility. Not all vendors support these transforms, but other vendors support only these transforms. Finally, notice that the transform sets in the commands are not necessarily the most practical. For example, both “PapaBear” and “BabyBear” have substandard transform-sets. You should use esp-rfc1829 and ah-rfc1828 together in the same transform-set.

Step 3: Create the Crypto Map

Crypto maps specify IPSec policy. Crypto map entries created for IPSec pull together the various security settings that set up IPSec security associations, including the following:

• Which traffic should be protected by IPSec (per a crypto access list)

• Where IPSec-protected traffic should be sent (who the peer is)

• The local address to be used for the IPSec traffic

• What IPSec security should be applied to this traffic (selecting from a list of one or more transform sets)

• Whether security associations are manually established or established via IKE

• Other parameters that might be necessary to define an IPSec SA

For IPSec to succeed between two peers, both peers’ crypto map entries must contain compatible configuration statements. When two peers try to establish a security association, they should each have at least one crypto map entry that is compatible with one of the other peer’s crypto map entries.

Using the ipsec-isakmp tag tells the router that this crypto map is an IPSec crypto map. Although only one peer is declared in this crypto map, a given crypto map can have multiple peers. The session key lifetime can be expressed in either kilobytes (after x-amount of traffic, change the key) or seconds, as shown in the following commands. The goal here is to make a potential attacker’s efforts more difficult:

The set transform-set command is where you associate the transforms with the crypto map. In addition, the order in which you declare the transforms is significant. You most prefer “MamaBear” in this configuration, and then the rest in descending order of preference to “BabyBear.”

The crypto map access list bound to the outgoing interface selects the IPSec packets that are destined to an IPSec tunnel. IPSec packets that arrive from an IPSec tunnel are authenticated/deciphered by IPSec and are subject to the proxy identity match of the tunnel.

The match address 101 command simply means to use access list 101 to determine what traffic is relevant. You can have multiple crypto maps with the same name (“armadillo,” in the following example) and different sequence numbers (“10,” in the following example). The combination of multiple crypto maps and different sequence numbers allows you to mix and match classic crypto and IPSec. You can also modify your PFS configuration here. PFS group1 is the default in the example given here. You could change the PFS to group2 or turn it off all together, which you should not do.

Step 4: Apply the Crypto Map to an Interface

The following commands apply the crypto map to the interface. Remember to apply the crypto map to the egress interface, not the ingress one. If you have multiple crypto maps that you want to apply to this interface, you must tack the name onto the list in the crypto map command:

INRGI(config)# int e0
INRGI(config-if)# crypto map armadillo

Remember that crypto maps and their access lists are direction-based (either inbound or outbound,) and that traffic not matching the access list is still transmitted without being encrypted.

Firewall VPN Configuration for Client Access

Cisco PIX Firewalls can be configured to terminate client VPNs, thus allowing users to access corporate resources securely.

Used with IKE, dynamic crypto maps can ease IPSec configuration and are recommended for use in networks where the peers are not always predetermined. You use dynamic crypto maps for VPN clients (such as mobile users) and routers that obtain dynamically assigned IP addresses.

Dynamic crypto maps can only be used for negotiating SAs with remote peers that initiate the connection. They cannot be used for initiating connections to a remote peer. With a dynamic crypto map entry, if outbound traffic matches a permit statement in an access list and the corresponding security association is not yet established, the PIX Firewall drops the traffic.

A dynamic crypto map entry is essentially a crypto map entry that does not have all the parameters configured. The dynamic crypto map acts as a policy template where the missing parameters are later dynamically configured (as the result of an IPSec negotiation) to match a peer’s requirements. This allows peers to exchange IPSec traffic with the PIX Firewall, even if the PIX Firewall does not have a crypto map entry specifically configured to meet all the peer’s requirements. Dynamic crypto maps are found for use by VPN Clients on PCs.

If the PIX Firewall accepts the peer’s request at the point that it installs the new IPSec security associations, it also installs a temporary crypto map entry. This entry is filled in with the results of the negotiation. At this point, the PIX Firewall performs normal processing, using this temporary crypto map entry as a normal entry, and even requests new security associations if the current ones are expiring (based on the policy specified in the temporary crypto map entry). When the flow expires (that is, all the corresponding security associations expire), the temporary crypto map entry is removed.

Like regular static crypto map entries, dynamic crypto map entries are grouped into sets. A set is a group of dynamic crypto map entries all with the same dynamic-map-name, but each with a different dynamic-seq-num. If this is configured, the data flow identity proposed by the IPSec peer should fall within a permit statement for this crypto access list. If this is not configured, the PIX Firewall accepts any data flow identity proposed by the peer.

You can add one or more dynamic crypto map sets into a crypto map set via crypto map entries that reference the dynamic crypto map sets. You should set the crypto map entries that reference dynamic maps to be the lowest priority entries in a crypto map set (that is, use the highest sequence numbers).

The procedure for using a crypto dynamic map entry is the same as the basic configuration described in the “Basic IPSec Configuration” section, except instead of creating a static crypto map entry, you create a crypto dynamic map entry. You can also combine static and dynamic map entries within a single crypto map set. Create a crypto dynamic map entry by performing the following steps:

Step 1 Assign an access list to a dynamic crypto map entry:

This determines which traffic should be protected and not protected.

For example:

crypto dynamic-map dyn1 10 match address 101

In this example, access list 101 is assigned to dynamic crypto map “dyn1.” The map’s sequence number is 10.

Step 2 Specify which transform sets are allowed for this dynamic crypto map entry. List multiple transform sets in order of priority (highest priority first):

For example:

crypto dynamic-map dyn 10 set transform-set myset1 myset2

In this example, when traffic matches access list 101, the security association can use either “myset1” (first priority) or “myset2” (second priority), depending on which transform set matches the peer’s transform sets.

Step 3 Specify security association lifetime for the crypto dynamic map entry if you want the security associations for this entry to be negotiated using different IPSec security association lifetimes other than the global lifetimes:

For example:

crypto dynamic-map dyn1 10 set security-association lifetime 2700

This example shortens the timed lifetime for dynamic crypto map “dyn1 10” to 2700 seconds (45 minutes). The time volume lifetime does not change.

Step 4 Specify that IPSec should ask for PFS when requesting new security associations for this dynamic crypto map entry, or demand PFS in requests received from the peer:

For example:

crypto dynamic-map dyn1 10 set pfs group1

Step 5 Add the dynamic crypto map set into a static crypto map set. Be sure to set the crypto map entries referencing dynamic maps to be the lowest priority entries (highest sequence numbers) in a crypto map set:

crypto map map-name seq-num ipsec-isakmp dynamic  dynamic-map-name

For example:

crypto map mymap 200 ipsec-isakmp dynamic dyn1

Chapter Summary

This chapter discussed what a VPN is and the many benefits that it brings to networks everywhere. The most popular benefit of implementing VPNs is the cost reduction and overall financial savings. The reduction of bandwidth costs has made VPNs one of the best solutions available.

This chapter focused on the best available VPNs: IPSec-based VPNs. To understand how they protect your data, the chapter examined all those different levels, phases, and types of processes that are involved in getting your data packets encrypted into your IPSec-based VPNs. This was a truly amazing task because the subject matter gets complicated quickly.

Chapter Review Questions

1. Is it possible to have unencrypted VPNs?

2. What are the three types of VPNs?

3. Select three VPN features and benefits and explain how your organization can directly benefit from each.

4. VPN Concentrators are designed for many users—explain how many and when they should be used.

5. Does the VPN Client Software for PCs support Apple’s powerful new operating system, MAX OS X?

6. When does split tunneling occur?

7. In relation to a data stream, what role does authentication play in securing it?

8. When tunneling data in IPSec, what are the three protocols that play a role in process?

9. In site-to-site VPNs, what are the two different encapsulating protocols and what are the differences between the two?

10. Name three of the benefits of IKE.