Fundamentals of MPLS VPNs

To understand MPLS VPN technology, it is important to know its basic concepts. This section explains the nomenclature used in MPLS VPN networks and how MPLS works in simple terms. One important differentiator of MPLS networks is that they employ a connectionless VPN technology. The concepts of MPLS and VPN technology are explained here.

Nomenclature of MPLS VPNs

RFC 2547bis, "BGP/MPLS IP VPNs," describes the nomenclature and definitions used in the MPLS VPN framework. More precisely, it defines IP VPNs, meaning that the VPN service accepts IP datagrams from customer sites and delivers them also as IP datagrams to other customer sites. The connection between a customer site and the core network, also referred to as an attachment circuit, may be a Layer 2 service such as ATM, but the VPN service handles only IP datagrams transmitted over this link.

Internally, an RFC 2547bis-compliant network uses the Border Gateway Protocol (BGP) to route VPN information across the core. This is invisible to the VPN customers, but it does have security implications for the operation of the network in that BGP is a vital part of the overall system and must be secured adequately by the service provider. On the CE-PE link, static routing can be used, as well as any dynamic routing protocol, such as BGP or RIP.

For the remainder of this book, the term "MPLS VPN" will be used for the type of VPN defined in RFC 2547bis unless explicitly stated otherwise.

This book uses the same nomenclature as the RFCs; they are listed here for your reference:

  • Service provider? The organization providing an MPLS VPN service to a customer.

  • Customer? An organization receiving an MPLS VPN service from the service provider. This organization can itself be a service provider, an enterprise or set of enterprises, an application service provider, or other organizational entities.

  • Core network? The network, which is provided by the service provider and to which the customers connect.

  • Customer edge (CE) router ? Used to connect to an MPLS VPN. It is typically located at a customer site.

  • Provider edge (PE) router? CEs connect to PEs on the MPLS core network. The PE is part of the MPLS core, and the service provider maintains it.

  • Provider (P) router ? Used inside the MPLS core, providing connectivity between the PEs. Normally, a P router does not have VPN information, but only information on how to reach the PEs.

Figure 1-3 shows an MPLS VPN network with connected VPNs. The core consists of PE and P routers. Customer routers (CEs) connect to the PEs. One PE can hold several CEs of different VPNs or the same VPN.

Figure 1-3. MPLS VPN Structure

[View full size image]


Three Planes of an MPLS VPN Network

Every network can be described by its three planes. This section describes the fundamentals of MPLS VPN networks by giving a brief description of the separate planes:

  • Control plane? The way control information is exchanged through the network

  • Data plane? How user traffic is forwarded through the network

  • Management plane? How the elements of the network are managed

Especially when discussing security in a network, it is important to clearly analyze each plane on its own because security problems might arise in any of them.

How the Control Plane Works

In MPLS VPN networks, the control plane is defined by various routing instances. The CE announces the IPv4 or IPv6 routes from its site to the PE, and the PE announces to the CE the routes from other sites of the VPN. This can be done through static or dynamic routing. In principle, any routing protocol is suitable for this link (BGP or OSPF, for example).

NOTE

The content of this book is equally applicable for IPv4 and IPv6 networks. Unless there is a difference in the handling of IPv4 and IPv6, this book uses the term IP without referring to the version.


On the PE, routing information for each VPN is held in a VPN routing/forwarding instance (VRF). Each VRF typically has some external interfaces to CEs associated with it, all belonging to the same VPN.

The ingress PE distributes the site's routes received from the CE and stored in the VRF to all other PEs that connect sites of this VPN. The routing protocol used for this is Multi-Protocol Border Gateway Protocol (MP-BGP). MP-BGP needs another protocol to find the egress PEs. There are various ways of doing this, but they are beyond the scope of this book. (See Appendix B, "Reference List.")

To keep the control information of various VPNs separate, the PE must distinguish various VPNs. This is done by prepending a so-called route distinguisher (RD) to every VPN route received from the CE. This effectively creates a new addressing scheme: instead of using normal IP addresses, the MPLS core uses VPN-v4 or VPN-v6 addresses, which consist of the route distinguisher plus the IP address of the VPN. So between PEs, MP-BGP exchanges VPN-v4 or VPN-v6 routes.

On a PE, the VPN-specific routing exchange is controlled by route targets (RTs). RTs define which routes on the MPLS core are imported to and exported from which VRF.

NOTE

Misconfiguration of RTs can easily compromise the security of a VPN because they control which routes are imported into which VRF. In Chapter 2, "A Threat Model for MPLS VPNs," this security risk is explained in detail.


On the egress side, the egress PE uses the same mechanism as on the ingress side between PE and CE?that is, static or dynamic routing. The addresses exchanged here are normal IP addresses.

NOTE

The CE does not have to know that it is connected to a VPN service. From the CE's perspective, the PE is just a core router. It does not have visibility of any other VPN, nor of the MPLS core.


Figure 1-4 displays schematically which protocols are used in an MPLS VPN environment and where: The core itself runs MP-BGP for the VPN-specific information and runs an IGP plus typically LDP internally. The CEs are connected to the core through any standard routing protocol or through static routing.

Figure 1-4. Control Plane in an MPLS VPN Network

[View full size image]


How the Data Plane Works

On the data plane, the CE forwards user traffic as normal IP traffic to the PE according to its routing table. Since the CE cannot "see" the core or other VPNs, the forwarding is the same as in any other network.

The PE forwards traffic from several VPNs, and because these VPNs may use the same address space, the forwarding on the MPLS core cannot use normal IP address space. Various methods are used to keep the traffic from different VPNs separate. This can be, for example, a Label Switch Path (LSP) or an IPsec tunnel. Common to all these methods is that the VPN traffic is carried in a type of tunnel. On LSPs, the most commonly used technique, the IP packet, is tunneled with a set of labels, as displayed in Figure 1-5. These labels distinguish the traffic of the various VPNs.

Figure 1-5. Labels Used in MPLS VPN Networks

[View full size image]


In most MPLS networks, the IP packet is attached to two labels:

  • Egress PE label? Used by the core to direct the packet to the egress PE

  • VPN label? Defines the VPN the packet belongs to

Both labels are removed before they are sent to the CE on egress, such that the egress CE receives a standard IP packet. The top label (PE label) is removed on the router before the egress PE, and before forwarding the packet to the egress PE. This technique is called "penultimate hop popping." This way the egress PE receives only the VPN label with the underlying packet. The egress PE uses the VPN label to find the egress VPN, removes the label, and sends the remaining IP packet to the CE.

How the Management Plane Works

The management plane for the MPLS core is the same as in other IP networks. All devices have in-band and out-of-band management channels, both of which are typically used.

The out-of-band channels are usually connected through a non-IP network, such as the phone network, and controlled through terminal servers, where the routers of a service provider's Point of Presence (PoP) are connected. These out-of-band channels are secured through the terminal servers.

The in-band management channel connects the network operations center (NOC) of the service provider to the devices that are to be managed over the IP network. Figure 1-6 shows in-band and out-of-band management channels. To secure this channel, several steps are necessary:

  • Each device needs to be secured by limiting access on the management channel to only the interfaces where this is required, and to only the source addresses that require access. In addition, strong authentication is required.

  • The entire MPLS network should block the management channels that are used from the outside, such that outside users cannot send packets to the management ports. This practice is also referred to as infrastructure access control lists (iACL).

  • The NOC must be protected against intrusions to avoid hackers to first take control of NOC systems, and then do device management from there.

Figure 1-6. Management Plane in MPLS VPN Networks

[View full size image]


All these points refer to operational best practices, which are described in detail in Chapter 5, "Security Recommendations."

In some MPLS networks, the service provider also manages the CE routers, which are typically located at the customer premises. For out-of-band access to these CE routers, the same rules apply as for core network devices, which makes out-of-band access quite a secure channel.

In-band access to the CEs, however, has to be designed with more attention to security: In many networks, the service provider provisions two logical links between the PE and the CE, one for the VPN and one for management. Figure 1-7 shows the connection between the PE and the CE, where there is a separate logical link into the management VRF of the CE. The VPN link is part of the VPN, and VPN users are not able to intrude into other VPNs or the core. However, through the second logical link the CE has a direct connection into the management VPN and from there into the NOC. This needs to be secured against attacks from the CE or the site behind the CE. Chapter 8 discusses the options and gives recommendations on how to secure the management access.

Figure 1-7. In-Band Management of CEs


Another way to manage the CE is to use the single logical link between PE and CE also for management. In this scenario, a single loopback interface on the CE is imported into the management VRF, and the IP address of the management subnet is exported to the VRF of the customer, and from there to the CE.

From a functionality point of view, both setups are equivalent: the management stations can access the CE. However, if the CE-PE link is logically split into a VPN link and a management link, as shown in Figure 1-7, the management network can by default be better protected: only the CE has access to the management station, whereas in the model with a single link the entire VPN has access to it. This is due to the fact that in the first model the management routes are kept in a separate VRF on the CE. Access from the VPN to the management network can and should be restricted by ACLs. The best place to put those ACLs is the PE ingress interface.

NOTE

Remember that the CE is always untrusted because the service provider has no physical access control over it. A customer might, for example, swap the CE to circumvent any security measures configured on it.


More detail about managed CE solutions can be found in Chapter 8.

NOTE

For more details on the MPLS VPN architecture and its functionality, refer to RFC 2547bis.


Security Implications of Connectionless VPNs

MPLS-based VPN services have increased significantly over the past years. One of the reasons for this is that they can be provided more easily than traditional Layer 2 VPNs, such as ATM and Frame Relay. This ease of provisioning often leads to attractive pricing models for the customer.

One of the reasons why MPLS VPNs are easy to provision is that MPLS VPNs are not connection oriented. Whereas most traditional VPN types consist of a number of provisioned point-to-point connections, MPLS is connectionless, as illustrated in Figure 1-2.

The connectionless nature of MPLS VPNs has many implications for scalability of the overall MPLS network, but also for security: On an ATM network, for example, a VPN customer typically will be presented with a number of virtual connections from a given router to all other routers that need to be connected. However, the customer needs to configure the router to use these virtual connections. The disadvantage here is that many virtual connections have to be configured on both the customer side and the service provider side. The advantage is that the customer has full visibility of the VPN and controls the connections.

On an MPLS network, the same customer router will in most cases be presented with a single connection into the MPLS network, and it is the MPLS network itself that decides where to forward packets to. The customer loses the view of the connections through the core. The advantage of this approach is scalability: the provisioning complexity is reduced to a single connection for each customer router; but the customer does not have visibility of the core network anymore. A service provider could maliciously or inadvertently introduce into a customer's VPN a router that does not belong there. The customer might not detect this and have lost the integrity of the network. In Chapters 5 and 8 this threat will be discussed further and solutions will be discussed.