Bending the MPLS Security Model - part 2 (Foundations)

The Foundations of MPLS Tomfoolery

In the previous post I briefly reviewed the constructs of MPLS services and how traffic is segregated. The key takeaways from that post are that:

1. Label switch routers generally only interpret / act on the outer label 
2. Basically all the security is provided / enforced through the control plane which restricts reachability by selectively advertising service labels
3. Routing for VRFs is different from normal IP due to the use of route distinguishers and route targets

Let's expand on how these points work in the attacker's favour.

All the intelligence in an MPLS network sits around the edge. It was designed this way so that the devices in the middle could dumbly (quickly) pass frames on, swapping one label for another without needing any knowledge of what the traffic is or how it should route. The core (P) nodes do not need to know anything about VRFs, IPv6 or even BGP - the edge PEs do all the protocol work, keep track of how that translates into labels and just hand labelled traffic into the core to be switched across to another node which understands.

Essentially the only security feature of the data plane is to drop frames with unknown labels. While you wouldn't expect to see it in the steady state, during many different types of legitimate convergence event frames can arrive with invalid labels attached. Generally this will only happen for milliseconds at a time but with high speed traffic flows or momentary loops that can mean a lot of frames. Mostly for this reason, I suppose, I've never seen a platform that logs or traps in the event of receiving an invalid label. This is helpful as it allows us to guess at labels without creating ridiculous amounts of noise.

Another less-thought-about aspect of (frame mode) MPLS is that the label space is platform wide, in other words it doesn't matter which interface receives a packet, only what the top label is. So no real sanity checking, and certainly no RPF checks (labels only indicate destination, not source) - frames can arrive from any angle and be treated the same.

All in all we have a system where all the decisions are made by the ingress PE. When a "customer" packet needs to be routed by the PE, it does a lookup to decide what service label is required (to indicate the correct VPN or pseudowire the egress PE) and what transport label should be applied (to indicate that the core should pass the traffic to the correct egress PE). Since nothing gets checked along the way, any device can send traffic to any service on any PE if the right labels are applied.

Label IDs are 20 bits wide, which would be a fair old area for an attacker to 'spray and pray'. Luckily for the attacker, though, the dynamic label assignment algorithms of various platforms are pretty predictable (in fact, they're usually sequential). The attacker is also helped by the fact that packets with invalid labels are silently dropped, leaving little in the way of evidence that anyone has been "poking around". 

The default dynamic assignment label ranges for a few common platforms are:

Cisco (IOS / IOS-XE): 16 upwards
Cisco IOS-XR: 16000 upwards
Juniper Junos: 100000 upwards
Alcatel 7750: 131071 downwards

Most kit will fall into one of these categories, so even if you don't know what kit is in use you still have a good chance of hitting the right labels.

A few relatively straightforward attacks spring to mind, each of which will be covered in separate blog posts. The scenarios are:

1. How to inject packets into a layer 2 EoMPLS pipe
2. How to trombone / MITM layer 3 VPN traffic
3. How to go after the PEs themselves

Stay tuned!