VPN Building Blocks

In this section we provide an overview of the technologies upon which a VPN is built. They include:

Access control
Authentication
Security
Tunneling
Service level agreements

Private data networks are still perceived as premium transport technology in comparison to IP VPN, or even ATM and Frame Relay networks. Such a perception is rather deeply rooted (perhaps due in no small part to concerted, almost century-old marketing efforts of telecommunications service providers, insisting on rock-solid security and robustness of their copper and fiber) but often quite unfounded. The most popular examples of such private networks are PSTN, private data leased lines, and dial-up networks in both wireline and wireless environments. In the following paragraph we demonstrate that networks based on dedicated private facilities suffer from the same operational problems as Virtual Private Networks provisioned over shared networking Infrastructures.

PRIVATE NETWORKS ARE SECURE

It is often said that a system is only as secure as its weakest link. Under this credo, a service provider's private networking facilities are only as secure as the individual elements of their networks, such as copper of fiber cables, circuits established over the air link (in the case of wireless communications), and switching and routing equipment on the data path. The weakest link of such a network is usually the physical environment, which cannot altogether be privatized or secured.

For instance, segments of private networks installed in rural and urban underground conduits (conveniently marked by various signs designed to help locate them) or aerial runs (cables on the telephone poles, reachable by almost anyone with proper equipment and protected only by an extra layer of plastic sheathing) are often unguarded and easily accessible not only by maintenance crews but also by unauthorized individuals with possible criminal intent. As a result, the data transmitted between two corporate divisions can be extracted from an underground fiber cable by simply stripping the sheathing and washing off the protecting gel, bending it, and capturing the escaping light with an inexpensive device used by phone company field technicians. The data transmitted over copper loops in metro areas can be accessed even easier by installing bridged taps in unprotected underground conduits or tapping directly into connecting terminals for the facilities routed through apartment building basements in metropolitan areas. Networks based on link layer technologies— such as ATM and Frame Relay—in addition to physical layer vulnerability, are often susceptible to network-based attacks such as malicious intrusion or eavesdropping.

In addition to transport facilities vulnerability, the data transported over private networks is usually not encrypted by either service providers or enterprises. Service providers, for some reason convinced of the Impenetrable nature of their cables and underground conduits, do not bother to implement any ciphering schemes or other encryption or authentication measures. Enterprise IT departments, convinced by service providers that the traffic will be carried only over their private (i.e., secure) facilities, in turn see no need to implement complex end-to-end security precautions.

The situation in cellular or wireless LAN communications is not much better. Access to the information transmitted over the air is even easier than to that transmitted over cables. Thus, early analog systems initially did not provide any data protection or even proper user equipment authentication and usually could be broken into by using inexpensive scanning and decoding equipment. This resulted in massive early analog mobile phone cloning fraud in the 1980s and 1990s.

The wireless industry responded with new digital systems that incorporated air interface ciphering schemes and mobile phone Subscriber Identity Modules-such as SIMs and USIMs-used in GSM and UMTS phones, respectively, to provide user authentication and ciphering. While these measures successfully addressed the mobile devices fraud problems, the issue of data security had not been dealt with equally effectively. The latest 2G and 3G digital cellular systems air interface ciphering schemes protecting the user data are often weak and expensive to implement and often do not have the desired effect on the public's purchasing decisions. Consequently, these systems are made optional in many commercial implementations. Examples include the GSM cipher, which has been broken and consequently updated, and CDMA2000 air interface security considered optional by the TIA standards and often not supported by equipment manufacturers.

PRIVATE NETWORKS ARE ALWAYS RELIABLE

Contrary to popular belief, sometimes leasing a dedicated facility may expose a company to more serious service disruptions and slower recovery than VPN-technology-based networks. Private networks based on dedicated circuits are much less reliable than technologies based on the use of virtual links (such as ATM, Frame Relay, or MPLS networks) or datagram-based solutions (such as IP VPNs), which allow for automatically rerouting the data flow over different virtual paths in case of intermediate link or node failures.

Often, private networks span significant distances over multiple interconnected facilities and traverse multiple types of data equipment, such as switches, routers, cross-connects, and SONET Add/Drop Multiplexers (ADMs). (SONET stands for Synchronous Optical Network.) In the case of a circuit or preprovisioned private line failure, data cannot be automatically rerouted through other paths, and communication is not possible until the service is restored. Incidentally, SONET rings were designed to address this problem, but only at the physical layer (the strongest link of the system) and usually not in end-to-end fashion. It is also rarely the only physical technology used in a private network, exposing an end-to-end path to survivability problems.

These building blocks are common to most types of data VPNs including MVPN. For this reason, their description will help prepare the reader for the detailed discussion of MVPN in Chapters 6 and 7.

Access Control

Access control in data networking is defined as a set of policies and techniques governing access to private networking resources for authorized parties. Access control mechanisms operate independently of authentication and security and basically define what resources are available for a particular user after the user has been authenticated. In the VPN world the physical entities, such as remote hosts, firewalls, and VPN gateways in the corporate networks involved in communication sessions, are usually responsible for or at least participating in enforcing VPN connection status.

Examples of decisions include:

Initiate
Allow
Continue
Reject
Terminate

The main purpose of any VPN is to allow selective, secure access to remote networking resources. With security and authentication but without access control, the VPN is only protecting transmitted traffic integrity, confidentiality, and preventing unknown users from using the network, but not networking resources. Access control usually depends on information about the entity requesting connection such as identity or credentials—as well as the rules defining access control decision. For example, some VPNs can be governed by a centralized server or other VPN control device located in the service provider's data center, or it can be administered locally by VPN gateway in private networks involved in VPN communication.

The set of rules and actions that defines the access rights to network resources is called the access control policy. The access control policy allows for the enforcement of a business goal. For instance, the policy "Allow access to remote access subscribers who have not surpassed 60 hours of usage" can be implemented by using RADIUS-based authentication of the user and incrementing a time counter every time a user gets access. In theory, a RADIUS DISCONNECT message (see [RFC2882]) may be used to interrupt the user session when the 60 hours are surpassed, but sometimes the policy may be enforced only at logon time, trusting users not to permanently stay logged on, or perhaps by putting a session duration limit that would put an upper bound on the usage exceeding the maximum allowed time. Similar policies may be implemented by replacing the time limit with a credit limit that may be associated to a prepaid account.

Policy Provisioning and Enforcement

The examples of standard-based policy provisioning and enforcement mechanisms include Lightweight Directory Access Protocol (LDAP), a standard for querying a directory, defined by [RFC2820], [RFC2829], and RADIUS. The service definitions and specific access instructions for both mechanisms are stored in centralized databases, accessible by the equipment responsible for access control decisions, such as IP routers, VPN gateways, or intelligent network appliances. The main advantages of these methods are simplicity and ease of management and provisioning. With LDAP, for example, changes in policies can be made by both the service provider and corporate IT administrator by accessing only one server housing a particular database instead of reprovisioning the information stored locally on many network elements.

The use of RADIUS binds the user authentication process with access control and service policy selection. Once the access policy is selected, its enforcement may take place at the device by querying a policy repository using LDAP. In recent years, another protocol named Common Open Policy Service (COPS—[RFC2748]) has been proposed to implement policy decision outsourcing and provisioning for very simple devices. Its use is so far very limited in the industry. However, it has been embraced by 3GPP Release 5 for media sessions authorization—that is, control of access to networks (possibly VPNs) used to offer multimedia services over third-generation systems.

Captive Portal

The access control function can be enforced at the point of termination of access protocols by admitting network access only after the access protocol authentication phase has completed successfully. Otherwise, it is possible to enforce network access control via a captive portal approach. This method is commonly used in Wireless LAN-based access networks and broadband access networks. It forces users to authenticate by filling in a form on a Web page, which is the only place they can access after gaining IP connectivity. This can be done via a TCP redirect functionality on ports 80, 8000, and 8080, which are typically used for the Hypertext Transfer Protocol (HTTP)—the protocol used to transfer Web pages.

The TCP redirect functionality—implemented on a network device or a plain router placed at the edge of a VPN (or any IP network)—inspects all IP packets up to the transport layer. If the protocol is TCP and the port number is recognized to be HTTP, the network destination address and the HTTP header are modified to request the Web page that corresponds to the portal credential input page. Alternatively, when the network device is not built to operate at the application level, the portal itself may have the intelligence to always respond to incoming HTTP requests from not registered (admitted) IP addresses by sending via HTTP the sign-on Web page. Once user credentials are collected and the user is successfully authenticated, the network device, informed by the portal, lifts the TCP redirect functionality and lets user traffic flow freely, perhaps until some other event—such as user inactivity timer, usage time or volume limit overflow, an interval allowed before new authentication is required, or even redirection to some advertisement page—does not modify this state.

Without going into further details that may not be entirely relevant to the main topic of this chapter, we think that this way to perform access control will become more and more widespread because of the shift in access technologies toward broadcast media such as WLAN, and because sharing access network resources may require a provider selection phase before service begins. In addition, the user may be prompted at provider selection time with a second (personalized) Web page with information on his or her account profile, promotions, and links to partners offering other fancy services. This might be located on VPNs or service networks and not accessible until a new (captive) portal-based access control phase has not been successfully conducted.

Some service providers do not even use the complexity of captive portals based on TCP redirect, perhaps because the equipment they have bought only inspects packets up to the network layer and can be configured only to allow access to certain network layer destinations. Instead, they provide access to users if they deliberately point their browsers to a URL printed on a subscription card or a prepaid card they are given. Once they go through the authentication phase, the network allows the user identified by the source IP address (and perhaps also the MAC/Layer 2 identifier) that was successfully authenticated access to all destinations.

Authentication

One of the most important functions VPN supports is authentication. In virtual private networking, every entity involved in communication must be able to positively identify itself to other involved parties and vice versa. Authentication is the process that allows communicating entities to verify such identities. One of the popular mechanisms for authentication widely used in today's networks is called PKI (see Chapter 2). This is known as certificate-based authentication, and the parties involved in communication authenticate each other by exchanging their certificates, which are guaranteed to be valid by a trust relationship with a certificate authority.

The authentication process may also involve providing shared-secret-based authentication information, such as a password or CHAP challenge/response pair, to an authenticator, such as an NAS, which in turn may look up a local file or query a RADIUS server. In this respect VPN operation encompasses two types of authentication: client-gateway and gateway-gateway. An example of client-gateway authentication in the GPRS packet data environment is RADIUS-based authentication of users accessing the GGSN. Only upon success are they admitted to an IPSec tunnel toward the customer network IPSec Gateway. The other case is common when site-to-site connectivity is set up, or when virtual dial-up networks are used and L2TP tunnel setup authentication is required between the L2TP Access Concentrator (LAC) and the L2TP Network Server (LNS).

Security

From the previous discussion we know that VPN by definition is built across public shared unsecured facilities, which makes data integrity and encryption its mandatory requirement. The VPN can be secured by deploying one of the available encryption or ciphering mechanisms combined with secure key distribution systems. These mechanisms are covered in depth in Chapter 2. We must mention, however, that security is not limited to the act of encrypting VPN traffic. It also involves complex procedures by the operator and its suppliers (for instance, in delivering SIM cards with secret key verification and algorithms), and when the VPN is network based (see the section "Labeling (MPLS) and VPN" coming up in the chapter for a definition of network-based VPN), there must be a trust relationship set up between the service provider and the VPN customer that requires agreement and deployment of appropriate security mechanisms. For instance, the AAA server in the corporation may be accessible only by securing RADIUS messages via IPSec as they transit over the shared infrastructure. Also, the AAA server may belong to a network not included in the VPN itself, to allow for isolation of AAA traffic from user traffic.

Tunneling as the VPN Foundation

Tunneling, originally covered in Chapter 2, is undoubtedly the single most important technology on which IP VPNs are built. Tunneling involves encapsulation of certain data packets within other packets according to a set of rules implemented at both ends of the tunnel. As a result, the contents of encapsulated packets become invisible to the public insecure network over which this packet is being transmitted. Examples of various tunneling technologies and definitions are provided in Chapter 2.

Note

A tunnel can have multiple endpoints when a multicast destination address is used.

The tunneling concept as applied to virtual private networking is depicted in Figure 5.1. Here the packets sent from remote host A to host Z must traverse many other switches and routers. If router C encapsulates the packet coming from host A and gateway Y decapsulates it, the other nodes traversed by this packet will only recognize the "outer" encapsulating packet and will not be able to obtain any information about its payload or final point of destination. This way, the payload of the packets sent between C and Y will only be recognized by these two network nodes and the hosts A and Z representing the origination and destination points of the data traffic. This effectively creates a "tunnel" through which packets are transported with the desired level of security.

Figure 5.1: Tunneling in virtual private networking.

The tunnel can be defined by its endpoints, the network entities where decapsulation occurs, and the encapsulation protocol being used. Tunneling techniques supporting VPNs such as L2TP or PPTP are used to encapsulate link layer frames (PPP). Similarly, tunneling techniques such as IP in IP and IPSec tunnel modes (all described in Chapter 2) are used to encapsulate network layer packets.

In the context of virtual private networking, tunneling may accomplish three major tasks:

Encapsulation (just described)
Private addressing transparency
End-to-end data integrity and confidentiality protection

Private address transparency allows the use of private addresses over a publicly addressable IP infrastructure. Since the contents of tunneled packet and its other attributes—such as addresses—are understood only beyond the tunnel endpoints, private IP addressing can be completely masked from public IP networks using valid addresses (Figure 5.2).

Figure 5.2: Private IP address masking via tunneling.

Integrity and confidentiality functions ensure that an unauthorized party cannot alter the tunneled user packets during transmission without detection and that the contents of the packet remain protected from unauthorized access. Moreover, tunneling can optionally protect the integrity of the outer IP packet header, thus providing data origin authentication. For instance, in IP VPN, it is possible to use the IPSec AH header to protect the tunnel endpoints' IP addresses from spoofing. However, in the data industry, in many cases this has not been considered important, and actually many VPN gateways do not even implement AH (see Chapter 2 for more details on IPSec, ESP, and AH). The reason is that if the tunneled user packet is ESP protected, and the packet encrypted using secure key distribution and management techniques and algorithms that cannot easily be broken, such as 3DES, then any attempt to use IP address alteration to intercept or to send traffic would be purposeless. There would be no way the malicious endpoints could correctly participate in the IPSec ESP-based security association, and thus detection of the incumbent security hazard would be easy, and the certainty that it would be very difficult to interpret "stolen" user data would be very high. This is what matters to VPN customers and thus justifies the quite limited usage of AH.

Note

AH may still be useful when tunnel setup control information needs to be provided. For example, this is mandatory to protect Mobile IP registration messages.

When tunneling is applied to create a Mobile VPN, these four functions (encapsulation, private addressing transparency, end-to-end data integrity, and confidentiality protection) must be accompanied by a set of mechanisms to provide for dynamic tunnel switching or reestablishment to support VPN user mobility. Later in this chapter, we discuss the details of this additional requirement. From Chapter 4 you may recall that modern cellular packet data systems, such as GPRS or CDMA2000, already include such schemes based on GTP and Mobile IP, which were originally designed to support mobility. The mobile tunnels based on these technologies can be concatenated to static tunnels at the edge of wireless networks to provide a variety of MVPN architectures. In the following chapters we describe in detail how these mechanisms are applied.

Labeling (MPLS) and VPN

The MPLS allows for nondestination IP address-based forwarding of IP packets over an IP backbone (see Chapter 2). One of the applications of this MPLS property is traffic engineering—that is, routing packets over paths determined by other criteria than mere optimal IP routing and perhaps based on the need to offer some level of QoS, or to select minimum-cost links or route over less utilized links to obtain load sharing. Another important application of MPLS is the provision of network-based VPN services between multiple-sites-based customer networks, also known as multisite VPNs. Network-based VPN, discussed in more detail later in the chapter, is a service offered by a service provider in an explicit way, via a provider edge (PE) router to customer networks. Provider edge routers normally connect to customer sites via customer edge (CE) routers via any Layer 2 or tunneling technologies, as well as MPLS.

The use of MPLS to offer VPN services is bound to the ability to control LSPs set up via some efficient VPN site's membership discovery/distribution protocol. There are mainly two schools of thought about the use of MPLS to offer VPNs. One camp thinks that a PE router fully controlled by the provider and equipped with multiple routing tables should be used, which we will refer to as the monolithic router approach. The other camp believes that the PE router should instead be based on virtual routers and that customers should have some degree of ability to manage them. We do not want to take a position on which is best, because, as it is often the case, practical considerations may suggest at times to use one method and at times the other. Rather, we will analyze pros and cons of each viewpoint.

The monolithic PE router approach is based on the ability of such router to support one routing table per VPN site, and each of these routing tables would advertise customer network site routes intradomain using the Internet Border Gateway Protocol (IBGP) and interdomain using BGP. In the case of a network prefix belonging to a site that overlaps with some other prefix of a different site advertised by the same PE router, the route would be accompanied by a route distinguisher to form the IPv4 VPN address family. This route may be associated to two additional BGP attributes—the Target VPN attribute and the VPN of Origin attribute—that would help in building a policy-based filter that can be used to configure VPNs on PEs. A label accompanying the route is also advertised, and the PE router includes its own IP address as the BGP next hop. The label is used as the inner label of a label stack that allows the IP packet to be sent from one PE to another PE, and to route the packet to the appropriate CE router based on the value of the label. This approach, described in [RFC2547], is widely implemented in the industry—largely because the leading industry vendor, Cisco Systems, is promoting it.

With the virtual router (VR) approach, the PE router supports software-based routers named virtual routers, each taking care of a particular customer network site. Since a VR is a regular router, customers can manage it and configure the forwarding equivalence classes (FECs) on it. Each PE VR belonging to a particular VPN can discover the other VRs through the use of OA&M, directory based methods, or a BGP approach such as the one described in [RFC2547].

For instance, it is possible to envision a GPRS operator who not only manages wireless access, but also makes its GGSN behave as the CE of a BGP MPLS, and uses MPLS VPNs to partition the network in VPNs devoted to different services. A GPRS operator may decide to create a MPLS VPN for intradomain packet data services that is offered to subscribers when they are not roaming and a VPN for roaming subscribers. This comes with the advantage that inter-PLMN backbone resources usage (such as IP addresses belonging to GRX blocks assigned to the provider for inter-PLMN operation) is minimized.

Service Level Agreements

Entities involved in virtual private networking, such as wireless carriers, ISPs, corporations, and remote users, are bound by certain agreements to achieve the desired levels of service as well as the desired revenues for the services provided. Such agreements, drafted between all the interested parties and their partners, that define quantifiable and measurable levels of service are called service level agreements (SLAs). SLAs have been used in many forms for quite some time in networking. However, they are especially important in the context of virtual networks relying on a shared infrastructure or a multitude of shared infrastructures—as is often the case with MVPN. In mobile data networks where relationships between peers are already fairly involved, more than one SLA might be required to support all services and cover all entities that might be involved in such services on the provider or the consumer side. Let's take a more detailed look at the issues involved in setting up a comprehensive SLA in a mobile environment.

MVPN SLA

MVPN SLAs are especially complex because they must include both wireless and wireline segments. Often, the performance of the wireless segment cannot be adequately enforced because of the inherently unpredictable nature of the air interface. Additionally, in the mobile environment a user may be roaming to a network outside the home mobile service provider's administrative domain, bringing up the issue of guaranteeing end-to-end service. The home service provider must somehow cascade the need to provide service guarantees in a framework roaming agreement, standard for all roaming partners. Such a roaming SLA would allow, with an acceptable degree of assurance, that the end-to-end service level guarantee can be met according to the performance figures promised to the customers. It is therefore likely that given the uncertain roaming and mobility patterns that may characterize mobile users and perhaps also because of unpredictable visited network conditions, Mobile VPN service providers may include in their SLA different service level guarantees for the cases when the user is roaming and when the user is in the home networks.

Following is a list of considerations you should take into account when compiling a SLA for a typical MVPN service:

Fixed tunnel availability
Fixed tunnel bandwidth guaranties
Fixed tunnel latency
Peak and sustained cell/packet rate
Packet loss rate
Session continuity guarantees (that is, a limit on the expected times the session could be lost within some coverage areas and under some constrained wide area mobility conditions)
Idle sessions timeouts (which may differ from those normally enforced by the corporate network access server, because of the need to save resources on the wireless network side)
Allowed roaming regions and performance when roaming

Having analyzed main VPN properties and underlying technologies, let's turn our attention to VPN classification.