A lot of people think MPLS is quite a secure technology - perhaps it's all the talk of VPNs or the fact that various government security standards permit the use of VRFs to segregate data at different security levels while VLANs are not considered secure enough. I've always thought that was a bit strange, because fundamentally when on the wire VLANs and MPLS both use a 4 byte tag to determine what can talk to what.
In this mini-series of blog posts I will briefly go through the building blocks of layer 2 and layer 3 MPLS VPNs, the controls these provide and a few gotchas before finally exploring some ways to use and abuse the mechanisms to cause mischief on the network.
Introduction to the MPLS Security Model
In addition to its unrivaled flexibility and scalability, the most significant benefit of MPLS is its very simple (and therefore fast) data plane:
- As frame enter at the MPLS edge, the PE adds (pushes / imposes) labels to the frame header.
- At each hop inside the MPLS core a simple table lookup is done on the outer label number. The lookup returns a replacement label, outgoing interface and encap to be written onto the outgoing frame (a label swap).
- As frames reach the edge of the MPLS core, the PE removes (pops) the outer label and acts on (i.e. routes, switches or processes) whatever it finds inside.
For "vanilla" MPLS networks, two labels are used. The first, or inner, label is used to indicate what layer 2 or layer 3 service should handle the frame. The second, or outer, label is known as the transport label and is used to get the frame to the correct endpoint. Service labels need only be understood by the ingress and egress devices, meaning that intermediate devices only need to be able to interpret and act on the transport label. So the transport label is to get where you're going, the service label is to do what you're doing.
Labelled traffic can be queued / scheduled at the interface for QoS purposes but once traffic is labelled there's very little that can be done with regards to manipulation. ACLs can't be applied to filter labelled traffic and, since there is no "source" field in an MPLS header, uRPF checking is not possible.
The whole security model of MPLS is premised on the fact that traffic cannot pass without the right labels and route / label learning is restricted by the control plane. For anyone not familiar with MPLS VPNs, I'll provide a very high-level introduction to how this happens in practice.
Layer 3 VPNs
In order to maintain several, possibly overlapping, routing tables, an MPLS router uses the concept of VRFs. A VRF is a distinct routing instance, a bit like a virtual router, with its own interfaces, routing table and routing protocols. Internally the MPLS router uses a route distinguisher, or RD, to keep one VRF's routes separate from another's.
Separation is achieved by basically bolting the RD onto the beginning of every IP prefix known within the VRF. So for instance, if VRF "A" uses RD 100:100, when it learns a route to 10.10.10.0/24 that will be known internally as 100:100:10.10.10.0/24. If an identical prefix is learned in VRF "B" with an RD of 200:200, that will be known internally as 200:200:10.10.10.0/24. Since the extended versions of the two prefixes are different, there is no conflict and both can be used independently.
Layer 3 MPLS VPNs use MP-BGP to share routing information between devices. MP-BGP works with the extended prefixes described above and any VPN route that will be advertised to other devices must have a
route target community attached (defined as an export route target for the VRF). That route can only be learned by another VRF, either locally or remotely, which is configured to import routes with that target.
In simple VPNs the import and export route targets match, meaning that every member VRF learns the routes that are present in every other member VRF. This produces a basic any-any connectivity model.
 |
| Any-Any VRF Topology |
Clearly, since each VRF learns routes from every other VRF there is a full mesh of connectivity.
The import and export can be controlled independently, so a variety of topologies can be created quite simply. For example, to create a hub and spoke setup, simply configure the hub to export the hub route target while importing the spoke route target and configure the spokes to export the spoke route target while importing the hub route target.
 |
| Hub and Spoke VRF Topology |
Spokes do not learn from each other because they only import routes with the hub target. Without knowledge of each other's routes, no traffic can pass between the spoke VRFs.
Another common application of multiple route targets is in setting up "grey management" VRFs - that is a single VRF containing centralised management platforms which are used for operational support and maintenance of devices in multiple customer VRFs.
 |
| Grey Management VRF Topology |
The grey management routes are leaked into each customer's VRF, providing reachability to the NMS. The management VRF in turn imports each customer VRF's routes to provide reachability to the managed CPEs. Typically the managed CPEs will each have a loopback address assigned from a known range and the management VRF will have an import filter allowing only the routes to those loopbacks to be imported. Public address space is usually used to avoid any addressing conflicts within the customer VRFs.
Gotchas
In both the hub-and-spoke and grey management scenarios there is a centralised point which has all the routing information and can communicate with everything, while the peripheral VRFs only learn a reduced set of routes and therefore can only communicate with the networks within their limited view. Spokes do not import the spoke route-target and therefore cannot "see" each other. Customer VRFs do not import each others' route targets and so separation is maintained.
One big mistake that can easily be made is for the spoke to accidentally advertise a summary or default route. The diagram below shows what happens in this case:
 |
| Hub and Spoke Topology Broken by Default Route |
The spokes still cannot learn each others' routes, however they do learn the default route from the hub. If PC B tries to send traffic to PC C's IP address, the traffic will follow the default route towards the hub. The hub knows all the spoke routes and so sends the traffic onwards towards PC C. So despite VRF B not containing any routes from VRF C and vice-versa, traffic can still flow between them.
The workaround: don't summarise or default route within overlapping or partial mesh VRFs, particularly at hub sites.
Layer 2 VPNs (Pseudowires)
MPLS pseudowires are essentially point-to-point tunnels that transport layer 2 frames using MPLS transport. A pseudowire simply takes a frame in one end and moves it, as is, to the other end. Pseudowires are typically signalled using targeted LDP - that is a Link Distribution Protocol connection directly between the PEs on each end of the pseudowire. The two endpoints communicate directly with each other to signal the labels to be used for a particular pseudowire, as differentiated by a virtual circuit identifier (VCID).
Since the necessary service labels are signalled directly between the two interested PEs, they are not known elsewhere in the network and no other devices can participate in the pseudowire, i.e. it is point-to-point.
Gotchas
Due to the simple nature of pseudowires, the gotchas are pretty minor. Provided the two peers are configured with matching VC IDs, most problems are going to be down to "schoolboy errors":
- Mismatched VC IDs
- Mismatched VC types (VLAN vs. Ethernet)
- Broken label-switched path between peers
- TLDP session unable to come up (control plane filters, mismatched LDP keys)
- Mismatched MTU (each vendor seems to count in a different way)
- Port MTU smaller than the configured VC MTU
Summary
This post really only reviewed at a very high level how MPLS VPNs are set up and how one is kept distinct from another. In the next post I will start to look at some weaknesses and opportunities for mischief.
