A planning framework for implementing virtual private networks - IT ...

A Planning Framework for Implementing Virtual Private Networks William Yurcik and David Doss

A

virtual private network (VPN) is simply secure network connectivity over a shared public network—basically, a private network on a public network infrastructure (the Internet). Figure 1 (next page) shows an example of a network layer VPN (adapted from Paul Ferguson and Geoff Huston, “What is a VPN? Part I,” The Internet Protocol J., June 1998, pp. 2-19). Corporation X’s subnetworks (which belong to a common administrative domain) have established a VPN (depicted by dashed lines) across a portion of the Internet. This VPN is invisible to competitor corporation Y even though it is using common transmission and routing resources. However, deploying a VPN is not so simple; it requires extensive planning because of its large up-front investment in hardware and software, lengthy set-up time, and ongoing maintenance. Here we present a planning framework for organizations based on an actual implementation experience (Samuel Patton, Bryan Smith, and colleagues,“A Virtual Private Network Deployment Framework,” Proc. IEEE Conf. Local Computer Networks, IEEE Press, Piscataway, N.J., 2000, pp. 225-226). Despite the common perception that a VPN is not a customizable solution, a broad spectrum of VPN options is available. Network designers do not anticipate any single

1520-9202/01/$10.00 © 2001 IEEE

VPN solution to supplant others. Instead they forecast that a diversity of choices will continue to emerge, increasing an advanced-planning framework’s value. Until recently, corporations relied primarily on leased transmission capacity or contracted data services from com-

Because there is no single VPN solution, it’s critical to have a planning framework to ensure successful deployment. mon carriers to create their own private wide area network (WAN). This model has drastically changed because of • decreasing costs for Internet connectivity, • increasingly higher bandwidth connections to the Internet, and • mature encryption technology for secure Internet communications. A VPN is virtual in that it has no corresponding physical network but rather shares physical circuits with other traffic. A VPN is private in that it isolates Internet traffic with routing and secures it with encryption. The use of “private” and “Internet based” to describe the same service appears to be an oxymoron, but we explain later how

VPNs manage to be both.

MOTIVATION Companies have several strong motivations for building VPNs; they provide • a uniform corporate computing environment that is transparent to users, • secure communications, and • the cost efficiencies of using a common public infrastructure versus building and operating a private WAN. While many networking technologies have not lived up to their initial hype, this is not the case for VPNs, which are being widely deployed and appear to be earning the nickname “very profitable networks.” A VPN not only drastically decreases cost but also increases May ❘ June 2001 IT Pro

41

PERSPECTIVES

Figure 1. A VPN connects corporation X with geographically remote subnetworks. X

X

Y

Y

Shared public links

Y

X

Routers

Y

flexibility because corporations can establish or release global Internet connections on demand.They can also initially pay for low bandwidth and increase bandwidth as demand grows. Internet connectivity is also a VPN’s major disadvantage: Guaranteeing quality of service (QoS) over the Internet is difficult because aggregate traffic flows can be unpredictable. Service-level agreements (SLAs) between Internet service providers (ISPs) and corporations are an evolving contractual solution designed to guarantee QoS based on throughput, availability, and/or response time thresholds.

DEPLOYMENT DECISIONS Many choices will confront you in considering how to deploy a VPN. Here we briefly describe the core choices such as the different types of VPNs, encryption, firewalls, and how to accommodate legacy systems.

Types of VPNs The several types of VPNs correspond to the various networking layers: data link, network, transport, and application. The most common VPN in use provides secure dial-up (data link) access. Here, we focus on network layer VPNs using IP routers; these VPNs commonly interconnect 42

IT Pro May ❘ June 2001

collection of tunnels between sites because routing is isolated.This isolation is possible because the tunnel egress addresses are within a VPN site’s address space, and the packets within the tunnel use a separate VPN address space. Tunneling can also encapsulate other protocols in a format that preserves their functionality. You should consider other options when deciding what type of VPN to use:

Y

LANs. The peer VPN model is one in which paths are computed on a hop-by-hop basis, where each node in the path is a peer with a next-hop node. The overlay VPN model is one in which the network-layer forwarding path is not calculated on a hop-by-hop basis. Rather, routers use the intermediate link layer as a “cut-through” to another edge node on the other side of a public network. A subtype of the overlay VPN model is tunneling, which is the practice of wrapping a packet with new header information and allowing an intermediary network to deliver it. The most common tunneling mechanism is generic routing encapsulation (GRE) tunneling from source to destination router, router to router, or host to host. Tunnels between source (ingress) and destination (egress) routers encapsulate source packets with a new GRE header and forward them into a tunnel with the tunnel’s endpoint as a destination address. When the packet reaches the tunnel endpoint, the last router strips the outer GRE header away, unencapsulating the inner packet. The router then forwards this original packet to its original destination, which appears in the inner packet header. You can thus create a VPN from a

• Consider using provisioned VPNs, which offer multisite connectivity across a single ISP backbone. Using a single ISP backbone enhances performance and security. • Think about combining all VPN functions into a single hardened box with added redundancy features, such as multi-homed connections—two or more independent connections—to multiple ISPs and fail-over backup. Such a configuration can be more robust than chaining together separate devices, each of which could fail separately. • Look for network equipment with a bandwidth from 10 Mbps to 100 Mbps and the ability to handle more than 1,000 simultaneous VPN tunnels per device.

Encryption Tunneling does not ensure privacy because networks typically transmit even encapsulated IP packets in plain text.This is clearly a problem if a corporation wants to use the Internet to transmit important business information. The evolving standard for network-layer encryption is IP Security (IPSec). IPSec supports two types of encapsulation, which are used in combination: an authentication header (AH) protocol and an encapsulating security payload (ESP). AH provides secure source identification and data integrity verification using a header field, but does not provide confidentiality—fields are left in plain text. ESP supports payload encryption for

confidentiality and has two modes: tunnel mode for WAN traffic (the entire packet, including source and destination addresses, is encrypted to prevent traffic analysis) and transport mode (only the payload is encrypted) for LAN traffic. Although most VPN vendors are moving to support IPSec, not all VPN products are interoperable. IPSec-based VPN traffic can also encounter layer-violating devices—that is, network devices that modify packets at the network layer or higher; network address translation devices are the most prevalent example. Such layerviolating devices do not support IPSec. In general and independent of IPSec, end-to-end encryption to individual end systems provides confidentiality with the highest level of authentication. However, such connections are open to traffic analysis because they must leave headers in plain text for intermediate network devices. For traffic between networks where interoperability may be a problem, the application layer must supply end-to-end encryption, which results in scalability problems for key distribution and client uniformity. Conversely, tunnel mode encryption transparently protects traffic between VPN subnetworks. It lets participating end systems remain undetected and disguises traffic patterns. VPN endpoint routers encrypt packets, however, traffic between end systems and the first-hop VPN router is in plain text. Any corruption of operation or traffic interception at tunnel endpoints will compromise the entire VPN. Hackers foiled in attempts to crack network traffic may instead target client machines. Alleviating these problems requires a certificate authority (CA) to issue and manage digital certificates exchanged by VPN devices and users. CAs solve the authentication scalability problems and make it

VPNs: An Historical Context The idea of using a public network to create the illusion of a private data or voice network—one devoted exclusively to specific subscribers—is not new. The first packet-based VPN emerged in 1975 when BBN delivered the first Private Line Interface (PLI) packet encryption devices to protect classified data for transmission over the Arpanet. Another example is Centrex service, which local telephone companies have offered for many years as a central-office switch service for providing private data and voice networks. In 1985, AT&T began offering softwaredefined networks (SDNs) for private voice networks based on dedicated and (later) switched connections; telephone companies billed users differently for on- and off-net calls.

practical to establish large VPNs. Widespread use of CAs will depend on the continuing deployment of public-key infrastructure (PKI), which includes directory services and key management, among other services. After you determine where you want to implement encryption, you must choose an algorithm type and key length appropriate to protect against expected threats. With this information you can estimate the processing resources that encryption will require. On average, it takes about 40 times more computing effort to route encrypted data than plain text. For this reason, it is essential to determine the processing level needed at peak times to effectively handle a given number of secure connections. Consider a coprocessor-based encryption engine for greater throughput. Knowing that no system is hacker proof, you must also have a plan for recovery if a hacker compromises your encryption algorithm.

Firewalls Tunnels and encryption do not obviate the need for firewalls to filter network route advertisements such that only specific networks receive routes that are within the VPN community of interest. Conversely, nonVPN routes are not forwarded within the VPN. This inability of VPN hosts

to respond to packets with source addresses from outside the VPN community of interest provides egress security. Ingress filters prevent outsiders from injecting external packets into the VPN. It’s also important to determine firewall performance based on VPN traffic loads. Firewall filtering options (static, dynamic, and stateful) have different performance levels, which you must weigh against perceived risks. For example, dynamic firewalls can modify their access lists based on day and time restrictions or suspicious events (unlike static firewalls), and slower stateful firewalls can be more powerful since they attempt to identify individual packets as part of valid TCP (Transmission Control Protocol) interactions. Also consider the use of a Web proxy. In addition to preventing direct IP connections to user machines, proxies can provide a stronger filtering capability. They can be built to monitor specific protocols and can enforce customized security options, such as the ability to filter out potentially malicious ActiveX or Javascript mobile code.

Accommodating legacy systems Because VPNs replace existing network services, a major concern is how May ❘ June 2001 IT Pro

43

PERSPECTIVES

VPNs will effect existing operations and applications.You must consider a migration path for existing network infrastructure and existing applications when creating a VPN. No single vendor or service provider has all the application interoperability answers for a VPN, and legacy applications will remain. Issues related to legacy systems include the following: • In a heterogeneous, multiprotocol environment, a VPN must support legacy protocols. • Encryption may block legacy network management functions. • As VPNs become larger, network management tasks grow exponentially, making outsourcing attractive; managed VPN services is a growth industry. • You should identify legacy networked applications and determine the effect of potential addressing changes. Examples include DNS and e-mail applications. • From a security perspective, the potential for undetected misconfiguration of general-purpose legacy operating systems makes them a poor VPN foundation. A detailed plan to deploy a VPN should include a pilot network with noncritical traffic. After successful

Resources We recommend these sources for further background on network-layer virtual private networks. ➤ “A Framework for IP Based Virtual Private Networks,” Bryan Gleeson and colleagues, Internet Engineering Task Force RFC 2764, Feb. 2000; http://www.ietf.org/rfc/rfc2764.txt. ➤ Virtual Private Networks, 2nd edition, Charlie Scott, Paul Wolfe, and Mike Erwin, O’Reilly, Cambridge, Mass., 1999. ➤ Virtual Private Networks: Technologies and Solutions, Ruixi Yuan and W. Timothy Strayer, Addison-Wesley, Reading, Mass., 2001. ➤ Virtual Private Networking: A View from the Trenches, Bruce Perlmutter with Jonathon Zarkower, Prentice Hall, Upper Saddle River, N.J., 2000.

completion of a pilot network, the plan should slowly migrate network partitions one at a time into the new VPN. You should simultaneously maintain the legacy production networks during the entire process—this overlay capability is one of the main flexibility features of a VPN. It is advisable to start with a minimal set of VPN features, gradually turn on new capabilities, and let the network stabilize. You should turn off the legacy production network only after the operations and user communities gain confidence in the new VPN.

EDITORIAL CALENDAR JULY/AUGUST Fault Tolerance

SEPTEMBER/OCTOBER Software Organizational Benchmarking

M

any people use the term “VPN” generically as if it were a single specific solution. In the end, however, each distinct VPN solution has its own strengths, weaknesses, and price tag; IT professionals must weigh these characteristics against business requirements. Future VPN research directions include taking advantage of the QoS capabilities of multiprotocol label switching (MPLS). MPLS is a method of assigning labels that tell routers where to send a packet and what priority that packet should receive, potentially combining the use of network-layer routing and per-packet switching with link-layer circuits and per-flow switching. ■

William Yurcik is an assistant professor of applied computer science at Illinois State University. Contact him at [email protected].

NOVEMBER/DECEMBER Ubiquitous Computing

David Doss is an associate professor and graduate program coordinator in the Department of Applied Computer Science at Illinois State University. Contact him at [email protected]. 44

IT Pro May ❘ June 2001