Virtual Private Network Overview

VPN technology enables enterprises to connect their sites together over a public infrastructure; it allows businesses to set up extranets between themselves, and telecommuters to connect to their office network. It has mechanisms that offer security and quality of service (QoS), enabling applications such as voice and video.

For enterprises buying VPN service (instead of building their own private network using, for example, leased lines) from an SP, the main benefits are price and flexibility. The lower prices and flexibility are the result of the SP's ability to reduce operational costs by consolidating its services over a single IP infrastructure. This consolidation leads to better use of resources and enables the provider to offer value-added services such as guaranteed QoS, multicast, redundant routes, fast path recovery, and so on, on a "get-what-you-pay-for" basis.

Two VPN models have been widely deployed in recent years: the CE-based ("overlay") model, and the PE-based ("peer-to-peer") model. Although they are briefly discussed in the following sections, the terminology is introduced here:

• Provider network This is the SP network, enabling connectivity between customer sites (also referred as P-network).

• Customer network This is the customer network, typically a set of customer sites, to be connected over the P-network.

• Customer site This is one, topologically contiguous customer site such as a campus or remote office.

• Provider device (P) An SP router that does not connect to customer sites.

• Provider edge device (PE) An SP router connected to VPN customer sites. The PE router marks the edge of the P-network.

• Customer edge device (CE) A customer router that connects the customer site to the P-network.

• Virtual private network (VPN) A set of customer sites that are allowed to communicate with each other and are subject to a common set of administrative policies. Note that a "site" can be a single remote user.

• IPv4 VPN A VPN that connects IPv4-enabled sites.

• IPv6 VPN A VPN that connects IPv6-enabled sites.

• Dual-stack VPN A VPN that connects separately IPv4-enabled sites and IPv6-enabled sites.

• Hybrid VPN A VPN that connects IPv4-only enabled sites and IPv6-only enabled site.

Many of the same techniques and mechanisms are used in both the CE-based and the PE-based VPN models. The difference between the two models is one of economy, politics, and administrative domains rather than technology.

IPsec is most often used in CE-based VPNs, and MPLS in PE-based VPNs.

The mechanisms and technology used in deploying IPv6 VPNs are the same as for IPv4 VPNs. Some differences apply as to how an IPv6 VPN will be deployed, however. Because IPv6 has enough addresses (to say the least), there is no need to use a private overlapping address range. Avoiding overlapping address space simplifies management and makes merging several private internets into a single private internet much easier.

A challenge for the deployment of IPv6 in general and IPv6 VPN in particular relates to its coexistence with IPv4. It is expected that the public infrastructure will migrate to IPv6 at a slower pace than some of the private networks. In a network where most of the core will remain IPv4 only, IPv6 VPNs will have to be tunneled over it. Benefits and issues related to tunneling are not specific to VPNs, and various mechanisms are reviewed in Chapter 3, "Delivering IPv6 Unicast Services," in the section "IPv6 over IPv4 Tunnels.") In an MPLS-enabled network, however, using a similar approach as 6PE (see Chapter 3, section "IPv6 over 6PE"), IPv6 MPLS VPN could run over an IPv4-based core without the drawbacks of tunneling. Such an implementation of IPv6 VPN is referred to as 6VPE and is discussed in the section "BGP-MPLS IPv6 VPNs: A PE-Based VPN Solution."

For a more in-depth study of VPNs, refer to the following books: VPN Applications Guide by David McDysan, and MPLS and VPN Architectures by Ivan Pepelnjak and Jim Guichard.

Provider-Provisioned VPNs

Provider-provisioned VPNs (PPVPNs) are VPN services operated by the SPs. Table 7-1 illustrates the taxonomy of PPVPN.

Table 7-1. Taxonomy of PPVPNs

PPVPN	L2 VPN	CE-based	L2TP: Layer 2 Tunneling Protocol.
		PE-based	VPWS: Wire service.
			VPLS: LAN service.
			IPLS: IP-only LAN service.
	L3 VPN	CE-based	IPsec. VPN knowledge limited to CEs.
		PE-based Per-VPN forwarding tables	BGP-MPLS IP VPN: The PE maintains VPN states to provide users isolation.
			Virtual router: The PE maintains a logical view per VPN.

Because layer 2 VPNs are transparent to higher-layer protocols, they are applicable to both IPv4 and IPv6. They also prove useful for transporting legacy System Networks Architecture (SNA) NetBIOS and IPX traffic, for which a layer 3 VPN solution is not available. They offer a quick path for supporting IPv6 VPNs.

CE-Based VPNs

CE-based VPNs can provide layer 2 or layer 3 services. CE routers connect together over the common infrastructure by the means of trunks. The trunks can be layer 1 (TDM), layer 2 (virtual circuit), or layer 3 (IP tunnels). The VPN can be operated by the user or the provider. In all cases, they terminate at the customer sites. The boundary between the private network and the shared public infrastructure is on the CE router. Any tunneling mechanism can be used to achieve CE-based L3 VPN, such as IPsec, 6to4, or IP-in-IP.

With IPsec, data integrity and confidentiality is guaranteed "end to end" (apart from the fact that there are no guarantees when it comes to security).

Other tunneling mechanisms, such as GRE tunneling, 6to4, or IP-in-IP, can also be used, but these have none of IPsec's security capabilities, unless of course, you use IPsec to secure them.

L2TP, specified in RFC 2661, is also used as a CE-based L2 VPN protocol.

CE-based VPNs can easily span multiple providers: the CE-to-CE tunnels work as long as there is IP connectivity.

Routing occurs between customer sites and is transparent to the SP; the customer network is an overlay on top of the provider network, which is used as a transport mechanism. To achieve effective routing, each site has to have a tunnel to every other site in what is called a fully meshed design. This would result in N(N1)/2 number of tunnels for N sites. Not only could the number of tunnels result in scalability issues on the routers terminating the tunnels, but the number also results in a huge cost of operating the network. Each time a new site is added, new tunnels must be created on all the other sites. Typically, some sort of hub-and-spoke network is used to work around this problem; however, this workaround might result in suboptimal routing.

QoS is also a problematic area for CE-based VPNs, especially when the VPN crosses multiple SPs. In this case, service level agreements (SLAs) are difficult to negotiate. In this respect, PE-based VPNs are better, not because they can offer better QoS, but because the provider has already prepared the network for QoS and can offer this as a value-added service as a part of the PE-based VPN offering.

PE-Based VPNs

PE-based VPN solutions involve the capability of the PE router to separate customer routing policies. Two approaches have emerged to achieve this. With the first approach, the physical PE router can be split into disjointed logical routers, each instance taking care of one VPN. With the second approach, each VPN routing table is managed independently by a single router exchanging routes between sites. The former is the so-called virtual router approach, whereas the latter is the BGP-MPLS IP VPN approach. You can use both with IPv6, but only BGP-MPLS IPv6 VPN has been implemented on Cisco routers.

In the PE-based VPN model, the CE router and the PE router share a common routing protocol and associated routing tables. A fraction of the PE is literally a part of the customer network, in charge of exchanging customer routes with remote customer sites by peering with remote PEs. CEs never peer directly; instead, they peer indirectly via PEs. Therefore, to achieve optimal routing, it is sufficient to mesh PEs, which are significantly less than the CEs of all customers (a PE can be attached to several customers). If you deploy MPLS PE-based VPNs, the data plane is operated independently of the routing plane, so that routing hubs do not result in suboptimal forwarding paths. Because routing uses the Border Gateway Protocol (BGP), it can leverage BGP mechanisms such as route reflectors to limit the number of peerings required.

Addressing Considerations

Regardless of the VPN model deployed, you must define an addressing plan for the VPN, one that allows hosts to communicate within one site, within one VPN (with other sites), and with public resources.

VPN IPv4 sites often use private addressing as defined in RFC 1918 for their addressing plan. These addresses do not need to be registered, and they are not routable on the public network. Whenever a host within a private site needs to access a public domain, it goes through a device exposing a public address on its behalf. With IPv4, this can be a Network Address Translator (NAT) or an application proxy.

Given the larger address space available with IPv6, the easiest solution to this problem is to use IPv6 global addresses for the private addressing plan.

Another approach is to use unique local addresses (ULAs), described in Chapter 2, "An IPv6 Refresher," in the section "Unique Local Unicast Address." According to Internet Draft draft-ietf-ipv6-unique-local-addr (Proposed Standard), ULAs are easier to filter at site boundaries based on their scope (well-known prefix structure). They are also Internet service provider independent and can be used for communications inside of a site without having any permanent or intermittent Internet connectivity.

When a host within a private site needs to access a public domain, it can either go via an IPv6 application proxy (such as a web proxy for accessing web pages), which will access the public resource on its behalf with a global routable address, or it can use a public address of its own. In the latter case, if ULAs have been deployed, the IPv6 host is configured with a routable global address, too. The source address selection algorithm, described in Chapter 2, is used to select one or the other based on the destination address.

Security Considerations

The two VPN models approach security in different ways. The goal of the PE-based model is to offer security similar to the layer 2 VPNs it was designed to replace. The CE-based model was designed by the IPsec working group and focused heavily on all aspects of security from the start.

Table 7-2 compares the security aspects of the two most deployed technologies of each model, IPsec and MPLS.

Table 7-2. Security Comparison Between IPsec and MPLS

Security Feature	IPsec	MPLS
Data confidentiality	Through encryption algorithms	By defining a single path between physical sites.
Data integrity	Through hashing algorithms	Not available, but separate routing lowers the risk of data alteration.
Data availability	None "extra." Relies on Internet transport. Redundancy can be deployed.	Relies on MPLS transport. Label switched path (LSP) can be protected by using private label tables. Redundancy can be deployed.

You can easily use IPsec to secure remote-access traffic. MPLS VPNs face the challenge of securing the traffic of a remote user as it traverses the network of an SP other than the one providing the VPN service. Solutions exist to enable the traffic to cross the SP boundaries, but they may entail deployment challenges. You can see examples in the section "Interprovider VPNs" as well as in Chapter 13, "Deploying IPv6 in an MPLS Service Provider Network."

Access to the Internet from a VPN is a challenge because such access can open a door for attackers. However, you can access the Internet from both VPN models, although more easily with IPsec, which does not separately manage private and public routing tables. In addition, poor implementations or complex configurations could easily defeat the best intentions. In that regard, it is important to note that IPsec puts most of the configuration burden on the CE, whereas for the MPLS VPN, the configuration complexity is on the PE, which typically is a router with more resources than the CE.

As with all security, it all comes down to whom you trust. MPLS VPNs provide no data confidentiality, and you have to trust the provider to get the configuration right, so that traffic is not leaked outside the VPN. In the IPsec case, you get data confidentiality, but only to the edge of the site. Because traffic inside the site is unencrypted, additional security policies need to be implemented. If communications must be confidential, traffic should be encrypted end to end. In that case, it does not make any difference whether the VPN itself provides data confidentiality.