Exploring the Basics of IPsec

This section begins by identifying the characteristics of an IPsec VPN. You will learn about various protocols that make IPsec VPNs possible, including IKE protocols and the ESP and AH protocols. Although you can have a Cisco IOS router act as a VPN termination device, Cisco has other network devices that can serve in this capacity, and you will be introduced to the Cisco VPN product family. Finally, you are presented with a collection of Cisco best practices for configuring an IPsec VPN.

Introducing Site-to-Site VPNs

Much of today's workforce (approximately 40 percent according to Cisco) is located outside of a corporate headquarters location. Some employees work in remote offices, and others telecommute. These remote employees could connect to the main corporate network using a variety of WAN technologies (for example, leased lines and PVCs, found in Frame Relay and/or ATM networks). However, these WAN technologies typically cost more than widely available broadband technologies, such as DSL and cable, which might also offer faster speeds.

As illustrated in Figure 15-1, these broadband technologies can be used to support virtual private network (VPN) connections between these geographically dispersed offices. These VPN connections are often called VPN tunnels. Even though a VPN tunnel might physically pass through multiple service provider routers, it appears to be a single router hop from the perspective of the routers at each end of the tunnel.

Figure 15-1 Site-to-Site VPN Connections

Branch A

Branch A

Figure 15-1 Site-to-Site VPN Connections

VPN Access Device

Branch C

VPN Access Device

Branch C

A remote-access VPN allows a user, with software on her client computer, to connect to a centralized VPN termination device. A site-to-site VPN interconnects two sites without requiring the computers at those sites to have any specialized VPN software installed. Table 15-2 defines the elements of a site-to-site VPN, which is the focus of this chapter.

Table 15-2 Site-to-Site VPN Elements Key __

Element

Description

Headend VPN device

Acts as a VPN termination device, located at a primary network location (for example, a headquarters location)

VPN access device

Serves as a VPN termination device, located at a remote office

Tunnel

Provides a logical connection over which traffic flows (for example, an IP Security [IPsec] tunnel and/or a Generic Router Encapsulation [GRE] tunnel)

Broadband service

Transports traffic to and from the Internet (for example, over a cable or DSL connection)

Overview of IPsec

Broadband technologies such as cable and DSL, in addition to other VPN transport mechanisms, often traverse an untrusted network, such as the Internet. Therefore, a primary concern with using a broadband technology as a VPN transport is security.

Different VPN technologies (for example, IPsec, GRE, L2TP, and L2F) offer different features. IPsec VPNs offer security features. Specifically, IPsec offers the following protections for VPN traffic:

■ Confidentiality: Data confidentiality is provided by encrypting data. If a third party intercepts the encrypted data, he could not interpret it. I Topic

■ Integrity: Data integrity ensures that data is not modified in transit. For example, routers at each end of a tunnel could calculate a checksum value or a hash value for the data. If both routers calculate the same value, the data most likely has not been modified in transit.

■ Authentication: Data authentication allows parties involved in a conversation to verify that the other party is who he claims to be. Various authentication methods exist:

— Usernames and passwords

— Biometric technologies (such as fingerprint analysis or retina scan)

— Preshared keys

— Signed digital certificates

IPsec not only becomes an attractive VPN technology because of its security enhancements. IPsec also scales to a wide range of networks. It operates at Layer 3 of the OSI model (the Network layer). As a result, IPsec is transparent to applications. That is, applications do not require any sort of integrated IPsec support.

IKE Modes and Phases

IPsec uses a collection of protocols to provide its features. One of the primary protocols it uses is Internet Key Exchange (IKE). Specifically, IPsec can provide encryption between authenticated peers using encryption keys, which are periodically changed. IKE does, however, allow an administrator to manually configure keys.

IKE can use three modes of operation to set up a secure communication path between IPsec peers. These modes are explained in Table 15-3.

Table 15-3 IKE Modes

Mode

Description

Main mode

Main mode involves three exchanges of information between the IPsec peers. One peer, called the initiator, sends one or more proposals to the other peer, called the responder. The proposal(s) include supported encryption and authentication protocols and key lifetimes. Additionally, the proposal(s) indicate whether perfect forward secrecy (PFS) should be used. PFS ensures that a session key remains secure, even if one of the private keys used to derive the session key becomes compromised. The three main mode exchanges can be summarized as follows:

Exchange #1: The responder selects a proposal it received from the initiator.

Exchange #2: Diffie-Hellman (DH) securely establishes a shared secret key over the unsecured medium.

Exchange #3: An Internet Security Association and Key Management Protocol (ISAKMP) session is established. This secure session is then used to negotiate an IPsec session.

Aggressive mode

Aggressive mode more quickly achieves the same results as main mode, using only three packets. The initiator sends the first packet, which contains all information necessary to establish a security association (SA) (an agreement between the two IPsec peers about the cryptographic parameters to be used in the ISAKMP session). The responder sends the second packet, which contains the security parameters selected by the responder (that is, the proposal, keying material, and its ID). This second packet also is used by the responder to authenticate the session. The third and final packet, which is sent by the initiator, finalizes the authentication of the ISAKMP session.

Quick mode

Quick mode negotiates the parameters (that is, the SA) for the IPsec session. This negotiation occurs within the protection of an ISAKMP session.

The IKE modes reflect the two primary phases of establishing an IPsec tunnel. For example, during IKE Phase 1, a secure ISAKMP session is established, using either main mode or aggressive mode. During IKE Phase 1, the IPsec endpoints establish transform sets (that is, a collection of encryption and authentication protocols), hash methods, and other parameters needed to establish a secure ISAKMP session (sometimes called an ISAKMP tunnel or an IKE Phase 1 tunnel). As a reminder, this collection of parameters is called a security association (SA). With IKE Phase 1, the SA is bidirectional, meaning that the same key exchange is used for data flowing across the tunnel in either direction.

IKE Phase 2 occurs within the protection of an IKE Phase 1 tunnel, using the previously described quick mode of parameter negotiation. A session formed during IKE Phase 2 is sometimes called an IKE Phase 2 tunnel, or simply an IPsec tunnel. However, unlike IKE Phase 1, IKE Phase 2 performs unidirectional SA negotiations, meaning that each data flow uses a separate key exchange.

Although an IPsec tunnel can be established using just IKE Phase 1 and IKE Phase 2, an optional IKE Phase 1.5 can be used. IKE Phase 1.5 uses the Extended Authentication (XAUTH) protocol to perform user authentication of IPsec tunnels. Like IKE Phase 2, IKE Phase 1.5 is performed within the protection of an IKE Phase 1 tunnel. The user authentication provided by this phase adds a layer of authentication for VPN clients. Also, parameters such as IP, WINS, and DNS server information can be provided to a VPN client during this optional phase.

Authentication Header and Encapsulating Security Payload

In addition to IKE, which establishes the IPsec tunnel, IPsec relies on either the Authentication Header (AH) protocol (IP protocol number 51) or the Encapsulating Security Payload (ESP) protocol (IP protocol number 50). Both AH and ESP offer origin authentication and integrity services, which ensure that IPsec peers are who they claim to be and that the data was not modified in transit.

However, the main distinction between AH and ESP is encryption support. ESP encrypts the original packet, whereas AH does not offer any encryption. As a result, ESP is far more popular on today's networks. In fact, AH is no longer supported in some Cisco implementations.

Both AH and ESP can operate in one of two modes—transport mode or tunnel mode. Figure 15-2 illustrates the structure of an ESP transport mode packet versus an ESP tunnel mode packet.

Figure 15-2 Transport Mode Versus Tunnel Mode

Transport Mode

Figure 15-2 Transport Mode Versus Tunnel Mode

Transport Mode

ESP

ESP

Payload

ESP

Original IP

Auth

Trailer

Header

Header

Tunnel Mode

ESP

ESP

Payload

Original IP

ESP

New IP

Auth

Trailer

Header

Header

Header

The following is a detailed description of the two modes:

.— ■ Transport mode: Transport mode uses a packet's original IP header, as opposed to

Topic adding a tunnel header. This approach works well in networks where increasing a packet's size could cause an issue. Also, transport mode is frequently used for remoteaccess VPNs, where a PC running VPN client software connects to a VPN termination device at a headquarters location.

NOTE You might be concerned that transport mode allows the IP address of the IPsec peers to remain visible during transit, because the original packet's IP header is used to route a packet. However, IPsec is often used in conjunction with the GRE tunneling protocol. In such a scenario, the original IP packet is encapsulated inside a GRE tunnel packet, which adds a new GRE tunnel header. The GRE packet is then sent over an IPsec tunnel. Even if the IPsec tunnel were running in transport mode, the original packet's IP header would still not be visible. Rather, the GRE packet's header would be visible.

One reason a GRE tunnel might be used with an IPsec tunnel is a limitation on the part of IPsec. Specifically, an IPsec tunnel can transmit only unicast IP packets. The challenge is, large enterprise networks might have a significant amount of broadcast and/or multicast traffic (for example, routing protocol traffic). GRE can be used to take any traffic type and encapsulate the traffic in a GRE tunnel packet, which is a unicast IP packet that can then be sent over an IPsec tunnel. Consider, for example, a multicast packet used by a routing protocol. Even though IPsec cannot directly transport the multicast packet, if the packet is first encapsulated by GRE, the GRE packet can then be sent over an IPsec tunnel, thereby securing the transmission of the multicast packet.

■ Tunnel mode: Tunnel mode, unlike transport mode, encapsulates an entire packet. As a result, the encapsulated packet has a new header (that is, an IPsec header). This new header has source and destination IP address information that reflects the two VPN termination devices at different sites. Therefore, tunnel mode is frequently used in an IPsec site-to-site VPN.

Cisco VPN Product Offerings

Cisco offers a wide array of VPN termination hardware:

■ Cisco VPN-enabled routers and switches

■ Cisco VPN 3000 series concentrators (which have reached end-of-sale [EOS] status)

■ Cisco ASA 5500 series appliances

■ Cisco 500 series PIX Security Appliances

■ Hardware acceleration modules

Cisco VPN-Enabled Routers and Switches

Many enterprise networks already contain Cisco IOS routers and/or switches that can serve as VPN termination devices. Examples of these Cisco IOS routers include the Cisco

Integrated Services Routers (ISR), shown in Figure 15-3.

Key Topic

Figure 15-3 Cisco Integrated Services Routers

Figure 15-3 Cisco Integrated Services Routers

With an appropriate feature set, a Cisco IOS router could act not only as a VPN termination device, but also as a firewall and intrusion prevention system (IPS) device. However, focusing on IOS-based VPN features, a Cisco router with an appropriate IOS offers the following:

■ Voice and video-enabled VPN: A voice and video-enabled VPN, sometimes called a V3PN, applies quality-of-service (QoS) features to traffic traveling over a VPN to treat different types of traffic with different levels of priority. For example, these QoS features could allow voice traffic to be sent over a VPN before sending less latency-sensitive traffic.

■ IPsec stateful failover: Because IPsec site-to-site VPNs can be mission-critical links, failover and redundancy should be considered in their configuration. Fortunately, Cisco IOS supports stateful failover for IPsec VPN connections, meaning that if one IPsec tunnel fails, and another IPsec tunnel takes over as a backup, the backup IPsec tunnel is aware of the previous session's parameters. Therefore, those parameters do not need to be renegotiated. Examples of redundancy and resiliency features supported by Cisco IOS include dead peer detection (DPD), Hot Standby Router Protocol (HSRP), Reverse Route Injection (RRI), and Stateful Switchover (SSO).

■ Dynamic multipoint VPN: Consider a hub-and-spoke VPN topology in which multiple remote sites have a site-to-site VPN connection to a headquarters location. In such a topology, if one remote site wanted to communicate securely with another remote site, the traffic would travel between the sites via the headquarters location, rather than directly between the sites. One fix for this suboptimal pathing issue would be to create a full mesh of IPsec site-to-site VPN connections, which would provide a direct IPsec VPN connection between any two remote sites. Such a solution, however, could be complex and expensive to configure and maintain.

A more economical solution to providing optimal pathing without necessitating a full-mesh topology is the Dynamic Multipoint VPN (DMVPN) feature. DMVPN allows a VPN tunnel to be dynamically created and torn down between two remote sites on an as-needed basis. Consider Figure 15-4, which shows a hub-and-spoke topology, with the headquarters acting as the hub. Branch B and Branch C want to communicate with one another. Therefore, a DMVPN tunnel is created between these two locations. Next-Hop Resolution Protocol (NHRP), Multipoint GRE (MGRE), and IPsec VPN features are required to support a DMVPN topology.

Figure 15-4 Dynamic Multipoint VPN

Branch A

Figure 15-4 Dynamic Multipoint VPN

Branch A

VPN Access Device

Dynamic Multipoint VPN Tunnel

Branch C

VPN Access Device

Dynamic Multipoint VPN Tunnel

Branch C

■ Integration of IPsec with MPLS: Many service providers use Multiprotocol Label Switching (MPLS) to intelligently forward traffic through a service provider's network, as opposed to using less efficient routing tables. Cisco IOS supports the mapping of an IPsec session into an MPLS session, which allows a service provider's VPN service to extend beyond the service provider's boundary.

■ Cisco Easy VPN: The Cisco Easy VPN feature helps facilitate VPN installations for remote-office and teleworker environments. The two components of Cisco Easy VPN are the Easy VPN Remote and the Easy VPN Server. The Easy VPN Remote component allows a variety of devices (including Cisco IOS routers) to receive security policies from a Cisco Easy VPN Server. The Easy VPN Server allows a variety of devices (including Cisco IOS routers) to push security policies from a central site to remote sites.

Cisco VPN 3000 Series Concentrators

Although Cisco 3000 series concentrators have reached EOS status, you still might encounter existing concentrators in some enterprise networks. A Cisco VPN 3000 series concentrator serves as a dedicated VPN appliance, as opposed to sharing VPN duties with other features, as is the case with a Cisco IOS router.

Consider the following features offered by Cisco VPN 3000 series concentrators:

■ Users can access a VPN via a web browser, as opposed to first installing VPN client software, using the Cisco WebVPN feature. This clientless access is made possible through the downloading of a small Java applet to the user's computer.

■ Robust endpoint security is provided via the Cisco Secure Desktop feature.

■ For terminal service applications, Cisco VPN 3000 series concentrators offer Citrix support. This support does not necessitate the installation of SSL VPN client software on end systems.

■ Cisco VPN 3000 series concentrators can be managed and monitored via a web interface.

■ Groups of Cisco 3000 series concentrators can be combined into a cluster. This clustering provides scalability and load balancing to VPN designs.

■ Cisco VPN 3000 series concentrators allow users to be authenticated using a variety of approaches, including one-time passwords, RADIUS, Microsoft Active Directory (AD), Security Dynamics International (SDI) Secure ID, and digital certificates.

Cisco ASA 5500 Series Appliances

Unlike a dedicated firewall, a dedicated VPN concentrator, or a dedicated IPS sensor, the Cisco Adaptive Security Appliances (ASA) can adapt to a variety of network security needs. For example, a Cisco ASA 5500 series appliance can simultaneously act as a VPN concentrator, a firewall, and an IPS sensor. However, because this chapter focuses on VPNs, consider the following VPN features offered by Cisco ASA 5500 series appliances:

■ Support for both IPsec and SSL tunnels

■ Scalability through clustering

■ Support for Cisco Easy VPN

■ Support for updating user computers with new Cisco VPN Client software

■ Support for Cisco IOS WebVPN

■ QoS support for converged voice, video, and data networks

■ Management via the Cisco Adaptive Security Device Manager (ASDM) graphical interface

Cisco ASA 5500 series appliances are available in a variety of models to meet the needs of a wide range of networks. As an example, Figure 15-5 shows a Cisco ASA 5540 appliance.

Figure 15-5 Cisco ASA 5540

Figure 15-5 Cisco ASA 5540

A network designer must choose an appropriate ASA model in addition to appropriate ASA licensing. Cisco ASA 5500 series appliances support the following types of licenses:

■ Feature licenses: Feature licenses allow a security appliance to support security

/ Key contexts (with the Security Context license) and General Packet Radio Service (GPRS) { Topic Tunneling Protocol (GTP) (with the GTP Inspection license).

■ Encryption licenses: Encryption licenses enhance a security appliance's ability to perform encryption by adding support for 3DES and AES encryption.

■ Platform licenses: Platform licenses dictate the scalability of a security appliance (for example, by limiting the number of concurrent VPN connections). As the name suggests, these licenses are platform-specific.

Table 15-4 compares various Cisco ASA 5500 series appliance models.

Table 15-4 Comparison of Cisco ASA 5500 Appliance Models

Cisco ASA 5500 Series Appliance Model/License

Cisco ASA 5505

Base/Security

Base/Security

Plus

Cisco ASA 5520

Cisco ASA 5540

Cisco ASA 5550

Target Environment

Small office/home office (SOHO)

Small to medium-sized business/small enterprise

Small enterprise

Medium enterprise

Large enterprise

Maximum 3DES/AES VPN Throughput

100 Mbps

170 Mbps

225 Mbps

325 Mbps

425 Mbps

Maximum Site-to-Site and RemoteAccess VPN User Sessions

10/25

250

750

5000

5000

Maximum SSL VPN User Sessions

25

250

750

2500

5000

IPsec andWebVPN Service Support

Yes

Yes

Yes

Yes

Yes

Cisco 500 Series PIX Security Appliances

Traditionally, Cisco PIX appliances performed firewall functions. The current line of Cisco PIX devices is the Cisco 500 series PIX Security Appliances, an example of which is shown in Figure 15-6.

Figure 15-6 Cisco PIX 535

Figure 15-6 Cisco PIX 535

Not only do Cisco 500 series PIX Security Appliances offer traditional firewall features, but they also offer a robust set of VPN features:

■ Enhanced support for spoke-to-spoke VPNs, allowing encrypted traffic to enter and exit the same interface

■ Support for Cisco TCP and UDP NAT traversal

■ The ability to enforce the use of security products on an end system (for example, Cisco Security Agent [CSA]) and to verify end-system VPN properties (for example, VPN client version and security policies)

■ The ability to block VPN connections based on the type of Cisco VPN client being used

■ Support for OSPF routing over an IPsec VPN

■ Integrated hardware acceleration on some Cisco 500 series PIX appliance models

Hardware Acceleration Modules

VPN operations, such as encryption, can become processor-intensive. Fortunately, Cisco offers the following hardware acceleration modules to offload much of a device's VPN

processing:

■ Advanced Integration Module (AIM): This is a daughter board that can connect to the motherboard of a Cisco router. The AIM can then be used to offload processor-intensive encryption algorithms from a router's main processor. A variety of AIMs, such as the AIM-VPN 3660, shown in Figure 15-7, are available for several models of Cisco routers.

Figure 15-7 Cisco AIM-VPN 3660

Figure 15-7 Cisco AIM-VPN 3660

■ Cisco IPsec VPN Shared Port Adapter (SPA): This is a module that can be inserted into either a Cisco Catalyst 6500 series switch or a Cisco 7600 series router, offering a scalable VPN solution to these modular devices.

■ Scalable Encryption Processing (SEP): This module can be inserted into a Cisco VPN 3000 series concentrator to offload DES, 3DES, and AES encryption processing.

■ Cisco PIX Security Appliance VPN Accelerator Card+ (VAC+): This can be installed into a Cisco 500 series PIX Security Appliance to boost the throughput of encrypted traffic. Specifically, the VAC+ supports a throughput of up to 425 Mbps for traffic traversing an IPsec-protected tunnel using DES, 3DES, or AES encryption.

VPN Design Considerations and Recommendations

When designing VPN connectivity for your network, the VPN components of the design should be as transparent as possible to end users and applications while still providing the security, performance, and reliability features expected from a VPN. Network design decisions vary based on specific network requirements. However, consider the following prioritized list of objectives when creating your VPN design:

■ Providing secure connectivity

■ Meeting reliability, performance, and scalability requirements

■ Offering options for availability

■ The ability to authenticate VPN users

■ Implementing security features for traffic before and after it passes through the IPsec VPN tunnel

As a reference, consider the following best-practice recommendations for identity and IPsec access control, IPsec, Network Address Translation, and selecting a single-purpose device or multipurpose device.

Best-Practice Recommendations for Identity and IPsec Access Control

A VPN design should provide a mechanism that allows VPN devices to be securely identified. This process of identification is called authentication. IPsec VPNs can use either preshared keys or digital certificates for authentication. Consider the following best practices:

■ VPN termination devices at each end of a site-to-site VPN tunnel can be configured with preshared keys (or can securely determine a preshared key using the Diffie-Hellman algorithm). Group preshared keys (which are associated with a group name identity) can be used only with remote-access VPNs. Also, wildcard preshared keys (in which all network devices use the same key) should be avoided in site-to-site VPNs.

■ Because digital certificates scale better than preshared keys, consider using digital certificates for VPN networks consisting of more than 20 devices. Also, because digital certificates have an associated lifetime, ensure time synchronization for devices using the digital certificates.

■ Certificate Revocation Lists (CRL) should be checked to make sure that a certificate appearing in a Certificate Trust List (CTL) has not been revoked (that is, it is still valid). Also, consider using an external certificate authority (CA) to vouch for the validity of a signed certificate when your VPN extends beyond corporate boundaries.

■ Evaluate the practicality of protecting digital certificates and preshared keys using a hardware-based solution, as opposed to a (typically less secure) software-based solution.

■ To filter unwanted traffic, consider applying inbound access control lists (ACL) on VPN devices.

Best-Practice Recommendations for IPsec

IPsec-protected VPNs offer a collection of features and options to select from. To help you make appropriate design decisions for your environment, consider the following Cisco best practices:

.— ■ Use IPsec to provide integrity checking in addition to encryption. You can do this by

Topic selecting the previously described ESP option, as opposed to the AH option.

■ Use strong encryption algorithms, such as 3DES and AES, as opposed to a weaker standard such as DES.

■ Use Secure Hash Algorithm (SHA) instead of Message Digest 5 (MD5) as a hashing algorithm because of SHA's increased security and speed.

NOTE There are legal limitations on exporting strong encryption algorithms outside the U.S. Consult the following URL for more information: http://www.cisco.com/wwl/ export/crypto.

■ You can attain an even greater level of security by reducing the lifetime of the Security Association (SA) being used or by enabling Perfect Forward Secrecy (PFS), which helps provide secure key generation. Cisco recommends that you avoid manipulating these parameters unless the data is highly sensitive. The reason for such a counterintuitive recommendation is the increased processor burden placed on the VPN device.

Best-Practice Recommendations for Network Address Translation

Network Address Translation (NAT) can help preserve a network's limited address space. However, some incompatibilities might arise when you use NAT in conjunction with an IPsec VPN. Therefore, when feasible, Cisco recommends avoiding the use of NAT for VPN traffic.

The only case in which Cisco does recommend the use of NAT for VPN traffic is when the network address spaces at the different ends of the VPN tunnel overlap. In that event, NAT can be used to accommodate the overlapping address spaces.

Best-Practice Recommendations for Selecting a Single-Purpose Versus Multipurpose Device

As previously discussed, VPN termination can be performed by a variety of devices, such as a dedicated VPN concentrator or a Cisco IOS router. A recurring design decision for VPN networks involves selecting a dedicated device to perform VPN functions versus selecting a device that will perform other functions (for example, firewall and/or IPS functions) in addition to its VPN duties.

When deciding between a single-purpose and a multipurpose device, think about the capacity and features offered by each device you are considering. For example, you might determine that a multipurpose device, such as a high-end Cisco IOS router, has more capacity than a single-purpose device, such as a low-end dedicated VPN device. However, the larger the network, the greater the likelihood that a dedicated VPN device will be an appropriate selection.

0 0

Post a comment