Build the Next-Generation Data Center
6 week online course starting on September 1st

I hope you knew this already: Backbone-hacking tools

A few days ago (the) Steve Bellowin sent an e-mail to the NANOG mailing list pointing to a FUD-full article describing upcoming release of MPLS hacking tools. Christian Koch quickly pointed out a similar presentation given by the same group @ Schmoocon and numerous respondents correctly stated these are old issues … if you’re interested in BGP and MPLS security, of course. Nicolas Fischbach even provided link to a 7 year old presentation describing numerous BGP/IGP/MPLS risks and attack vectors.

I went through the presentation and it does not describe anything we wouldn’t have known already. The capability to fake platform-wide MPLS labels has been known since the times MPLS (then known as Tag switching) was running mostly in PowerPoint. We’ve thus always recommended that the Service Providers should not run MPLS with their customers.

Carrier’s carrier architecture is a different story; it separates VRF labels from global labels.

The Carrier Ethernet attacks described in the presentation are also pretty obvious. If someone is brave enough to have a bridged solution spanning the globe (lots of people got burnt doing that 15 years ago, but obviously it’s best to learn from your own mistakes), he’s literally asking an intruder breaking into one of the sites to attack other sites with L2 techniques.

By now you might wonder why I’m writing this post. While the “All your packets are belong to us” presentation does not describe new vulnerabilities, it’s still a nice eye-opener for someone who thought SP MPLS infrastructure is absolutely secure (more about that in tomorrow’s post). It’s not and if you’re an enterprise network with high security requirements, you should take your own precautions, including running IPSec over SP MPLS network.


  1. Good post. I thought Monique Morrow's book "MPLS VPN Security" was a good overview of this topic (from my perspective as someone who's conversant but not expert at MPLS).

  2. Many of us did know this - my current employer uses various carriers' l3vpn services extensively, and we've always been worried about the possibility for issues like this, as well as the potential for occasional misconfigurations (which has happened to us several times - VRF/CoS misconfigurations where, say, EF-tagged traffic ends up shunted to some other VRF). The other problem that we've needed to solve is persistent MPLS blackhole events - LSP failures (of whatever sort) that don't express themselves as route withdrawals at the PER. Run enough IPSLA across these networks and you'll find that it's a relatively constant issue (to the extent that it interferes with real-time flows), regardless of provider. So, running mGRE/IPSEC from remote sites tends to ameliorate both problems, assuming adjacencies across the tunnels, and tunnels across different MPLS cores so that you can fail away from one of those events.

    Radia Perlman's paper on "Routing with Byzantine Robustness" is an interesting read, when considering these issues - she ends up at a similar stance: encrypt it all in stateful tunnels. I do think that the blackholes we've seen are a good example of a byzantine network failure (i.e., PER claiming to have reachability to a given prefix, when it does not).

  3. Sorry, meant to include a link to that paper:

  4. @Kevin: Thanks for the comment. I haven't realized the LSP failure were so common in some networks (we don't see them too often).


You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.