Virtual Private Networks
This chapter is from the book
This chapter is from the book
This chapter is from the book
5.1 Introduction
In Part 2, we discuss virtual private networks (VPNs). Chapter 4 had some examples of VPNs, but we were interested mainly in their tunneling aspects and didn't dwell on their security and authentication features.
In this chapter, we define VPN and briefly revisit the VPNs from Chapter 4. In the rest of Part 2, we study several types of VPNs, see how they are used, and take note of their strengths and weaknesses. As we shall see, these VPNs can operate at any layer in the TCP/IP stack. As usual, we will be less concerned with the administrative details of configuring the VPNs than with developing an appreciation for the protocols themselves and the manifestation of those protocols on the wire.
Before beginning our discussion of VPNs, we should agree on a definition for them. We already have an implicit definition from our study of MPLS VPNs in Chapter 4. We might say that according to that definition, a VPN is a method of using tunneling to build a private overlay network on top of a public network in such a way that the security of the private network is equivalent to that provided by leased lines. But this definition suffers from a lack of precision as to the meaning of "security equivalent to that provided by leased lines" and is a bit too general for our purposes.
Instead, let us say that a virtual private network is an overlay network built with tunnels in which the tunnel payloads are encrypted and authenticated. Given that we use robust encryption and authentication, such a VPN would certainly provide security as good as or better than that provided by leased lines, so this definition is consistent, if more restrictive, than that for MPLS VPNs. The underlying notion of both definitions is that we are trying to create the illusion of a private network while using a public network, such as the Internet.
It's worth dwelling, for a moment, on the differences between a "real" private network and a virtual private network. As a first approximation, we could say that real private networks provide security by physical separation of the underlying communication media. Separate leased lines are dedicated to the network, and these leased lines carry traffic only for that network. This means that short of a physical wiretap, an attacker does not have access to network traffic.
As we saw in our study of MPLS VPNs, the security of real private networks does not necessarily depend on the actual separation of physical media. We can also achieve segregation of network traffic through routing, or by multiplexing several data channels onto a single physical cable.
MPLS VPNs are an example of providing a private network by using routing to ensure that a private network's traffic is delivered only to intended recipients. Because the assignment of the MPLS label, and thus the route, takes place within the MPLS cloud, an attacker on the edge of the MPLS network has no way to capture traffic from another private network or to inject packets into it.
In a typical transcontinental leased-line deployment, the customer is provided with a partial or whole T1 line. Even if the entire T1 line is dedicated to a single private network, the traffic from the user's T1 line is multiplexed onto a higher-bandwidth backbone, such as a T3 or OC4 line, for transport across the continent to the other endpoint's T1 line. Thus, traffic from the private network is carried on the same physical media as traffic from other networks. Nevertheless, from the point of view of a user of the private network, this data is inaccessible and as a practical matter does not exist.
Despite the realities of the previous paragraphs, our normal conceptual model for a leased-line connection is a dedicated wire from one site to another. This model includes the notion of a physical connection, and when we're told that the network is down, we imagine that a physical event, perhaps involving a backhoe, has taken place. A virtual private network, on the other hand, is just that: virtual.
As with a TCP connection, a VPN's tunnel is a purely notional construct consisting of shared state at the tunnel endpoints. When told that the VPN is down, our first thought is not that a cable has been cut but that the shared state has become desynchronized. Once one of the VPN's packets enters the Internet, it is like any other IP datagram in the Internet. A malefactor can use a flooding attack to cause a router to drop it or can inject phony packets into the VPN by forging some of the packet's header fields. To protect itself from these and other attacks, a VPN relies on encryption and authentication to secure its data.
The advantages of a VPN over an actual private network should be clear. Instead of expensive leased lines or other infrastructure, we can make use of the relatively inexpensive, high-bandwidth Internet. More important in many instances is the ubiquity of the Internet. In most developed areas, access to the Internet is readily available without special provisioning or long waiting times. Given a VPN with robust cryptographic primitives and protocols, we could argue that a VPN is, in fact, more secure than a dedicated leased line, even if we accept our conceptual model of such a line as real.
In our definition of VPN, we said that the tunnel payload is protected by encryption and authentication. As we study the various types of VPNs, we will see that the meaning of payload depends on the class of VPN. In Chapter 6, for example, we study SSL tunnels, which operate primarily at the application layer. Thus, the payloads that they encrypt and authenticate are usually application data. At the other end of the spectrum, tunnel-mode ESP in IPsec (Chapter 12) operates at the network layer, so its payloads are entire IP datagrams.