A Review Paper on MPLS VPN Architecture

Transcription

1 32 A Review Paper on MPLS VPN Architecture Tejender Singh Rawat 1, Manoj Kumar Pandey 2, *Upendra Kumar 3 1, 2, 3 - Assistant Professor, ECE Department, ASET, Amity University Haryana Abstract A Virtual Private Network (VPN) provides private network connections over a publicly accessible shared network like internet, instead of using leased lines. A number of VPN technologies have been outlined, among which IPSec VPN and SSL VPN are the most commonly used. In this paper we will discuss the integration of Virtual Private Network (VPN) with other technology like MPLS (i.e. Multiprotocol Label Switching). This integration of MPLS with VPN has been receiving much attention from industries and standards bodies as it enables service providers to provide IP services with key benefits like qos, traffic engineering and optimal routing over a shared MPLS backbone. This paper will focus on the integration of providing VPN services in an MPLS environment. 1. Introduction The IP-based VPN technology is rapidly becoming the foundation for the delivery of future Internet services and many service providers are offering value-added applications on top of their VPN transport networks [1]. Using MPLS, the service providers can deliver the IP VPN services that businesses demand across either switched or routed networks [2, 3]. MPLS is the enabling technology that protects today's rapidly growing VPN revenue sources, while paving the way for tomorrow's value added services portfolio [4]. This paper provides an overview of the MPLS VPN technology and compares it with other types of VPN. An implementation of VRF over MPLS using MP-BGP [5] protocol is presented that discusses the key benefits of MPLS-VPN. 2. VPN Structure or Models A virtual private network (VPN) can be defined loosely as a network in which customer connectivity amongs the multiple sites is deployed on a shared infrastructure that utilizes the same security, management, and qos policies that are applied in a private network. VPN services can be offered based on two major paradigms: 1. Overlay VPNs, whereby the service provider furnishes virtual point-to-point links between customer sites. 2. Peer-to-Peer VPNs, whereby the service provider participates in customer routing The overlay model: Tunnel-based VPNs The traditional approach for service providers has been to provide Tunnel-based managed VPN service, by setting up secure, end-to-end connections, often emulating leased lines or virtual circuits, over public networks, according to the overlay model. A tunnel has two end points where the security service is both negotiated and rendered. Tunnels can exist at several protocol layers Layer 2 tunnels. They carry point-to-point data link connections between tunnel endpoints in remote access VPN. Two layer 2 tunneling protocols are commonly used today. The Point to-point Tunnel Protocol (PPTP) [6] provides authenticated and encrypted access from Windows desktops to Microsoft or third-party remote access servers with a double encapsulation of the network layer datagram with PPP and a modified version of generic routing encapsulation (GRE) [7]. The IETF standard Layer 2 Tunneling Protocol (L2TP) [8] also provides authenticated tunneling by creating

2 Layer 2 tunnels across a variety of networks (e.g. IP, ATM). Recently, Cisco has pioneered the new L2TPv3 protocol, based on optimized extensions to L2TP standard that includes signaling enhancements, a new encapsulation header, and a protocol identifier to support the end-to-end transportation of multiple Layer 2 protocols such as ATM and Ethernet Layer 3 tunnels. They provide IP-based virtual connection and in this approach normal IP packets are routed between tunnel endpoints that are separated by any intervening network topology. These facilities are now provided by the IPSec protocol suite. IPSec provides three basic communication necessities: confidentiality, secure communications and authentication and data integrity and between parties. At the core of the IPSec architecture [9] is the concept of security association (SA), specifying security services that should be applied to the traffic. The IKE (Internet Key Exchange) Protocol enables the automatic negotiation of SAs between two IPSec entities. Data security and integrity are provided with many encryption/hashing algorithms (e.g. MD5, SHA1 and 3DES) The peer model: Network-Based VPNs. As said before, the peer model is based on a Layer 3 connectionless architecture offering the advantages of a highly scalable VPN solution in which some or all VPN capabilities are deployed within the service provider's network. A customer site is required to "peer" with only one router located at the service provider's points of presence (POPs), as opposed to all other VPN terminators or customer routers in the same VPN. Actually the most promising approach to peer model VPN is based on the Multi-Protocol Label Switching (MPLS) technology that is rapidly emerging as a core technology for next generation networks, in particular optical networks. MPLS is essentially a hybrid routing and forwarding strategy, streamlining the backbone switching of IP packets between the network (Layer 3) and transport (Layer 2) mainly focused on improving Internet scalability through better Traffic Engineering practices and qos provisioning Layer 3 (or IP-based) MPLS VPNs. It leverages the BGP routing protocol already in use at the edge of ISP networks to propagate MPLS VPN information across the network. In more detail, MPLS is used to forward packets while BGP is used to distribute VPN routes over the backbone. The information about MPLS VPNs can be propagated via BGP on the Internet's backbone routers between different ISPs and Autonomous Systems by encoding customer IPv4 address prefixes into unique VPN-IPv4 NLRIs (Network layer reachability information). In this context, an NLRI is a prefix associated to a VPN route. Furthermore, through the use of the Extended BGP community attribute, the PE routers are able to control the distribution of these routes within the MPLS-VPN domain and between different AS. The interior of an MPLS VPN network is made up of MPLS-aware provider (P) router devices forming the MPLS core that are not directly connect to any VPN terminating router. Provider edge (PE) routers that surround the core devices enable the VPN functions of an MPLS VPN network. MPLS core and PE routers work as label switch routers (LSR) that are devices capable of switching packets based on their MPLS-imposed labels. The VPN-terminating router is referred to as a customer edge router (CE) and thus a VPN consists of a group of CE routers connected to the MPLS backbone PE routers [11]. Only the PE routers are aware of the VPN. The CE routers are not aware of the underlying network and perceive that they are connected via a true private network. Each RFC2547 MPLS VPN is associated with a VPN routing/forwarding instance (VRF). A VRF defines the VPN membership of a customer site attached to a PE router. 33

3 A separate set of routing and forwarding tables is maintained for each VRF preventing information from being forwarded outside a VPN and also preventing packets that are outside a VPN from being forwarded to a router within the VPN. This is the mechanism that allows the VPN traffic to be kept in separate contexts. Within each VPN, there is any-to-any connectivity: each site can send IP packets directly to any other site in the VPN, without having to go through a central site. In an MPLS VPN, the customer sites run ordinary IP. They do not need to run MPLS, IPSec or any other special VPN functions. A route distinguisher (RD) identifies each individual VPN. It is used to prefix the IP addresses involved in the different VPNs giving us a way to tell duplicate private addresses apart, to distinguish them. The RD is configured at the PE router as part of the VPN setup and is not visible to the customer. MPLS-VPN enforces traffic separation between customers because forwarding within the MPLS backbone is based on stacked labels. The MPLS LSPs setup begins and terminates at the PE routers while the CE routers perform normal routing. The incoming interface on the PE is used to determine which forwarding table to use when handling a packet because each incoming interface on a PE router is associated with a particular VPN Layer 2 MPLS VPN. AToM is a framework for encapsulating and transporting Layer 2 frames across the MPLS network, fully supporting Layer 2 services such as ATM VPNs, while aggregating and integrating transport technologies and taking advantage of proven MPLS quality of service (QoS) and scalability. It can transport ATM AAL5, Ethernet, Frame Relay, PPP, and Cisco HDLC packets. Currently, AToM only provides "like-to-like" transfers across the IP/MPLS backbone not allowing any kind of interworking between distinct layer 2 technologies. Actually, the ATOM technology is still under definition/development and not yet matures for performance analysis, so the layer 2 VPN paradigm will not be exploited in our evaluation. 3. VPN performance and scalability Issues The operational challenge of managing many separate highly meshed VPNs has served to highlight the performance and scalability limitations of traditional VPN technology based on the overlay model. For example, with an IPSec fully meshed VPN, each VPN gateway needs to know about every other gateway with which it will communicate. This requires the establishment and management of N-squared tunnels (or links) that are overlaid on top of the service provider network. This creates the operational challenge Classical VPNs strengths and drawbacks: Overlay/Tunnel-based VPNs offer several advantages. Enterprises can take any basic IP transport service and add VPN capabilities external to an ISP s network; the encryption and tunneling operates end-to-end and also is independent of intermediate routers and switches. These kinds of VPNs can thus be used in regions where service providers do not yet offer IP VPN services and, because the enterprise rather than the service provider control VPN access, customers aren t held hostage to slow VPN provisioning policies. And, just as tunnel-based VPNs can span enterprise IP networks, they can also span multiple Internet peering points and operate across multiple interconnected ISPs. This extends their reach to extranet partners who may be served by different service providers. But encrypted-tunnel VPNs also have significant limitations. If an enterprise chooses to provide the tunnels, it also has to assume responsibility for operating the encryption, key management and authentication systems, and ensuring that these systems are configured to match corporate security policies. Encryption can tax the throughput of routers and servers, reducing performance, and tunneling IP packets reduces network efficiency, a 34

4 key concern for anyone using limited-bandwidth, dial modem connections. Moreover, encryption is often incompatible with the network address translation (NAT) between small office/home office locations and ISP networks. The lack of correlation between VPNs and particular paths limits the service providers ability to allocate bandwidth or adjust QOS parameters in switches and routers for a particular VPN. The result is that neither enterprises nor service providers may have control over encrypted tunnel VPN performance. Scalability, as previously stated, is the most significant problem. Tunnel-based VPNs are an overlay type of network in which they ride on top of another networking technology, usually IP. Because of this overlay, a tunnel must be established between every site, which can lead to a very inefficient network. There are two typical layouts we will examine in detail here: a hub-and-spoke and a fully meshed configuration. The hub-and-spoke configuration consists of one central (hub) site connected to many remote (spoke) sites. This is the most practical configuration for a tunnel-based network. The hub site VPN terminating equipment is usually a very expensive one depending on the number of spokes since every spoke establishes a tunnel to the hub site. This model is not optimal for spoke-to-spoke communications. Any packets from one spoke to another spoke must first pass through the hub, requiring the hub to perform its steps to deencapsulate, de-encrypt, determine forwarding path, encrypt and encapsulate for every single packet. The latency will be higher compared to what it would be if the two sites communicated directly. The obvious solution to this would be to create a fully meshed network. However, this type of configuration has many drawbacks, the most critical being scalability. The number of tunnels needed to support a fully meshed encrypted tunnel network geometrically increases with the number of sites. Provisioning can be a problem. A provisioner must configure every tunnel. Configuring a single tunnel is not such a problem, but the time required to bring up a VPN increases dramatically as the size of the network grows. Fully meshed networks are the worst case. Supporting and troubleshooting this type of network could also be difficult for a service provider. Another consideration is about terminating devices. A provider needs to ensure all of them will interoperate properly. The easiest solution is to use the same devices at every location. However this is not always possible. Many times a customer will have a mix of their own devices that they wish to re-use. While interoperability is not as big a problem today, it is still an issue that must be dealt with when using this technology. Security is yet another consideration. Every VPN terminating device must be accessible to the public Internet and relies on encrypted tunnels to securely transmit data between sites. Therefore, every of these devices must have security measures in place, such as a firewall, to protect every location. Every firewall would need to be opened to allow provisionary access to the devices, which in itself can be a security risk. The management of each firewall becomes very difficult as the network grows in size A scalable solution: MPLS VPN. As stated above, when creating a VPN using connectionoriented, point-to-point overlays, such as Frame Relay, or ATM virtual connections (VCs) or tunneling-on-ip techniques, the VPN s key deficiency is scalability. MPLS-based VPNs, instead, are structured according to a pure peer model-based and connectionless architecture to leverage a highly scalable solution. First, according to the peer model, a customer site is required to peer only with one provider edge (PE) router as opposed to all other PE or customer edge (CE) routers that are members of the VPN, eliminating the proliferation of point-to-point customer-terminated tunnels or Virtual Circuits. Furthermore, the other great advantage of MPLS VPNs is that they are inherently connectionless. The Internet owes its success to its basic technology, TCP/IP, built on a packetbased, connectionless network paradigm. This means that no prior action is necessary to establish 35

5 communication between hosts, making it easy for two parties to communicate in a very effective and flexible way. To establish privacy in a connectionless IP environment, classic tunnel-based VPN solutions impose an often complex negotiation/setup procedure on a connection-oriented, point-topoint overlay created on the network. Thus, even if it runs over a connectionless network, a classic VPN cannot take advantage of the ease of connectivity and service flexibility available in connectionless networks. On the other side, when you create a connectionless VPN, you do not need tunnels and encryption to ensure network privacy, thus eliminating significant complexity. Other scalability issues of MPLS VPNs are due to the partitioning of VPN and IGP/EGP specific routes between the provider edge (PE) routers and the provider (P) routers in the network core. In detail, PE routers must maintain VPN specific routes for those VPNs terminated on their interfaces and P routers do not need to maintain any VPN routes but only those necessary for the core IGP/EGP routing activity. This increases the scalability of the provider s core and ensures that no one device become a scalability bottleneck [13]. Another significant technical advantage of MPLS VPNs is that no intelligence is required in the VPN terminating devices, since all of the VPN functions are performed in the core network and are transparent to the customer device, that does not need to be VPN aware or have to support IPSec or other tunneling protocols. This means the customer can use much less expensive devices or even continue using existing devices to terminate VPN. Latency is kept to minimum because packets are not encapsulated or encrypted. Encryption is not required since an MPLS VPN creates an entirely private network connection, ensuring, as asserted before, security levels very similar to those provided by a frame relay or ATM network. From the topological point of view, it is very simple with this technology to create optimally connected fully meshed VPN networks since there are no tunnels or Virtual circuits to set-up. The default configuration is in fact a full mesh. Sites connect directly to a PE and then can reach any other sites in the VPN. So, also in a logical hub-and-spoke VPN architecture, if the hub site should become unreachable, remote spoke sites can still communicate with each other. As part of their VPN service, providers may wish to offer premium services defined by SLAs to expedite traffic from certain customers or applications, controlling the mix of bandwidth, delay, jitter, and packet loss in the network. The key to an effective, network-wide IP QoS plan is scalability. A scalable way to provide higher levels of service quality with minimal loss in granularity is to implement multiple service classes, or classes of service (CoSs). Support for VPN CoS is provided within and between VPNs. CoS is an important requirement for many IP VPN customers. Network traffic is classified and labeled at the edge of the network before aggregation according to QoS policies defined by subscribers and implemented by the provider and transported across the provider core. Provisioning is also much easier in an MPLS VPN network. Provisioning only needs to be done on the backbone network equipment. Access to the customer terminating devices is not required. Once a site has been configured, it does not need to be revisited to add additional sites later. As new sites are added, configuration changes are only done to the PE they connect to. Because MPLS VPNs are connectionless, no specific connection maps or topologies are required. You can add sites to intranets and extranets and form closed user groups. When you manage VPNs in this manner, it enables membership of any given site in multiple VPNs, maximizing flexibility in building intranets and extranets. In addition, to make a VPN service more accessible, customers of a service provider can design their own addressing plan, independent of addressing plans for other service provider customers. MPLS VPNs allow customers to continue to use their address spaces without network address translation (NAT) by providing a public and private view of the address. A NAT is required 36

6 only if two VPNs with overlapping address spaces want to communicate. This enables customers to use their own unregistered private addresses, and communicate freely across a public IP network. Security can be much easier to implement with an MPLS VPNs. MPLS VPN security is accomplished by using a data plane and control plane approach. The data plane protects against a packet from within a MPLS VPN from traveling outside of its VPN boundaries and from packets from outside a MPLS VPN traveling into the boundaries of a MPLS VPN. The service provider will ensure that routers will drop packets that do not belong to MPLS VPN by examining the label of the packet. Control plane security ensures that non trusted peers cannot inject routes into the MPLS VPN. This is accomplished by the use of the MD5 authentication feature of BGP. Control plane security will also ensure that physical security of the routers is maintained to eliminate unauthorized access. From a security perspective, it is important to note that whereas MPLS VPNs provide traffic isolation, similar to ATM or frame relay it does not include a mechanism to provide strict confidentiality through encryption. However, if the layer 2 separation provided by partitioned routers and reserved paths is not considered sufficient for the security requirements of the user and strong encryption is required, IPSec and MPLS can be used together. The RFC 2547 MPLS VPNs describes an approach that uses Tunnel Mode IPSec. 4. Virtual Routing and Forwarding (VRF) The PE routers participate in the routing and IP numbering plans of each directly connected customer, creating Virtual Private Routed Networks (VPRNs). Many of IP numbering plans may overlap (such as the commonly used 10.x.x.x address space). The PE routers need to ensure that traffic destined for Company A's 10.x.x.x network will not be delivered inadvertently to Company B's 10.x.x.x IP network. To do this, the PE routers must maintain separate opaque routing and forwarding tables for each directly connected customer. These routing instances are called VPN Routing and Forwarding tables (VRFs). 5. MPLS VPN Routing PE VPN routing and forwarding tables need to be populated with the correct routing information for the attached VPNs. This routing topology data must be isolated for individual VRFs and cannot be allowed to leak into other VRFs. This separation is accomplished by adding an identifier known as a route distinguisher to traditional IP route advertisements. Route distinguishers are 8-byte blocks that are placed in front of an IPv4 network route advertisement. All VRFs must have unique route distinguishers. A route distinguisher may be represented as 200:50. In this example, 200 is the ASN of the ISP and 50 is the number assigned to that particular VRF. This numbering system ensures that all VRFs will have universally unique identifiers, even if they cross multiple ISPs. The route distinguisher is the mechanism that facilitates the use of overlapping customer IP address spaces; it associates each of these addresses with the correct VRF. Routing updates are accomplished via an extension of the Border Gateway Protocol (BGP). All PE routers communicate with each other via Interior BGP (IBPG) with Multiprotocol extensions. BGP updates are always based on the import and export routing policies configured within each individual router. For a VRF to be instantiated within a PE router, an explicit policy must be in place to accept (import) and propagate (export) the particular route distinguisher associated with that VRF. Route Distinguisher = Type + ASN + Assigned Number VPN-IP Address = Route Distinguisher + IPv4 Address. 37

7 6. MPLS VPN Strengths The following are the primary strengths of MPLS based VPNs. Scalability A well-executed MPLS-based VPN deployment is capable of supporting tens of thousands of VPNs over the same network. MPLS-based VPNs scale well because they do not require the full-mesh, end-to end site peering across the network. Security MPLS provides traffic separation between VPNs by using unique route distinguishers. Route distinguishers are assigned automatically when the VPN is provisioned and are placed in packet headers to provide traffic separation. They are not seen by end users within the VPN group. MPLS VPN privacy is similar to the privacy in traditional WAN infrastructures such as Frame Relay and ATM. Traffic Engineering by deploying traffic engineering in the core, service provider network engineers can implement policies to help ensure optimal traffic distribution and improve overall network utilization. MPLS enables traffic engineering by allowing traffic to be directed through a specific path based on least-cost routing, link utilization, latency, jitter, and other factors. Support for SLAs A well-executed MPLS-based VPN implementation supports SLAs and service-level guarantees (SLGs) by providing scalable, robust QoS mechanisms, guaranteed bandwidth, and traffic engineering capabilities. 7. Conclusion In today s economy where the most important objective for an engineer is to implement the new emerging technologies for transferring the data securely and in a cost effective manner. This venture of new technology i.e. MPLS over the existing technology i.e. VPN provides benefits that service providers need urgently in their networks, such as scalability, manageability and security. MPLS VPN offers many advantages including support for TE, QoS provisioning and scalability enhancements, the requirement of having MPLS support throughout the entire network is limiting its widespread usage. It would be an excellent choice for providing VPN services as it combines the benefits of both Overlay and Peer-to-Peer networks. Furthermore by using MPLS core the Service Provider can make use of other MPLS Features such as Traffic Engineering, Quality of Service and Network Management. 8. References [1] Francesco Palmieri, "Evaluating MPLS VPN against traditional approaches", Eighth IEEE Symposium on Computers and Communications (ISCC'03), June 30, [2] Ahmed Abdelhalim, "IP/MPLS-Based VPNs Layer-3 vs. Layer-2", Foundry Networks, Inc. June [3] Tim Wu, "MPLS VPNs: Layer 2 or Layer 3? Understanding the Choice", Riverstone Networks, [4] Dr. Hosein F. Badran, "Service Provider Networking Infrastructures with MPLS" in Sixth IEEE Symposium on Computers and Communications (ISCC'01) July 05, [5] E. Rosen, Y. Rekhter, "BGP/MPLS VPNs" RFC 2547, March [6] K. Hamzeh, G. Singh Pall, W. Verthein, J. Taarud, W.A. Little: Point-to-Point Tunneling Protocol PPTP, IETF draft: draft-ietf-pppext-pptp-02.txt, [7] S. Hanks, T. Li, D. Farinacci, P. Traina: Generic Routing Encapsulation over IPv4 networks, RFC1702,

8 [8] A. Valencia, K. Hamzeh, A. Rubens, T. Kolar, M. Littlewood, W. M. Townsley, J. Taarud, G. Singh Pall, B. Palter, W. Verthein: Layer Two Tunneling Protocol L2TP, IETF draft: draft-ietfpppext-l2tp-10.txt, [9] S. Kent, R. Atkinson: Security Architecture for the Internet Protocol. IETF draft: draft-ietf-ipsecarch-sec-04.txt, [10] E. Rosen, Y. Rekhter: BGP/MPLS VPNs, RFC 2547, [11] S. Previdi: Introduction to MPLS-BGP-VPN, Proceedings of MPLS Forum 2000, [12] G. Heron, L. Martini: An Architecture for L2VPNs, IETF draft: draft-ietf-ppvpn-12vpn- 00.txt, [13] R. Pulley: Implementing VPNs Using MPLS, Proceedings of MPLS Forum 2000,