IT Jobs
The trouble with MPLS
High-end carrier services can mean high-end configuration issues and risks.
By Jon Espenschied, Computerworld | Computerworld UK
Published: 01:00 GMT, 14 May 07
Multi-site and outsourced IT operations are making good use of Multiprotocol Label Switching (MPLS), but strange trouble is turning up more and more. Often in discussion with local network staff, we come to the point when I ask about backhaul lines or Internet service providers over which they presumably run a site-to-site virtual private network (VPN). They happily reply, "Oh, we have MPLS" and provide a network diagram consisting of a suitably inscrutable cloud.
Life is not so simple. Increasingly, those IT infrastructures appear functional, but a simple scan turns up many times the number of hosts that ought to be visible. Finding rogue devices on a network is cause for a bit of alarm, but unknown subnets?
What's going on? MPLS is supposed to simplify wide-area networking with carrier-grade service, not increase the risks of exposing sensitive data. Finding one's network cross-connected with another organisation is not something that can be dealt with tomorrow, and a serious address-space collision can put networks completely out of commission.
IT managers and technologists looking for a simple way to connect distant LANs turn to MPLS as a solution that has more currency and expandability than older offerings. The trouble is many of them make the decision to adopt MPLS without enough information.
Blue car, yellow car
As its name implies, MPLS embeds network switching or routing information into lower network layers. Like frame relay, it allows low-latency transit of network traffic between two distant points but leaves error handling up to the endpoints. Like asynchronous transfer mode, it embeds transit information into lower network layers, but the variable-length packets of MPLS are more suited for encapsulating IP traffic than ATM's fixed-length cells.
By labelling traffic at a lower network level, less processing has to happen at each waypoint between source and destination. It's analogous to colour-coding cars on the highway and allowing only blue cars to enter at the Los Angeles on ramp and exit at San Francisco and vice versa. Yellow cars might share the same road from San Diego to Santa Barbara, but they would enter or exit only on ramps flagged for yellow cars.
The transit speed is unchanged -- MPLS doesn't make a 10Mbit/sec. link go to 11 -- but the entry, routing and exit decisions can be made much more simply and quickly. To send someone to San Francisco, you could give them a blue car, and the network (the road) would get him there without needing to get on and off the highway to ask for directions.
The devil's in the details. RFC 3031 defines MPLS, but it takes a subsequent half-dozen RFCs to cover the more drowsy topics of label distribution, handling, application and interfaces with other networks. MPLS configuration is, as others have noted, expensive and tedious, which is why the technology has been the domain of carriers for the better part of a decade.
It's misleading, then, when uninformed LAN administrators think an MPLS connection "just works." Simply plugging two network endpoints into a carrier's MPLS cloud may allow those networks to communicate, but without some attention, anyone else connected to the cloud may also be visible.
In more than one instance, an organisation with just a couple of private IP, Class C subnets (192.168.1.x and 192.168.2.x, for example) discovered dozens of other subnets (such as 192.168.50.x) with thousands of live hosts. Its MPLS router was smart enough to sort out subnet mapping when the IP traffic from other sites was "popped" out of the MPLS cloud on the their side (avoiding wholesale IP collision), but without configuration to indicate otherwise, it was just one big happy network.
Compliance and the cloud
What do you do when suddenly there are a lot more blue cars than you expected? And what about the other organisations wondering who's scanning their networks from a rogue host through their MPLS routers? For any organisation concerned about the US Sarbanes-Oxley and Gramm-Leach-Bliley Acts, or the PCI (Payment Card Industry) data security standard, it's quite a mess.
Who sorts out requirements for labelling before an MPLS network is provisioned? Often no one, as it turns out.
A carrier may provide a basic configuration that works, but an uninformed customer may unwittingly buy a low-end MPLS service with fast traffic handling but no isolation from the carrier's other customers. The carrier assumes that the client knows it's a semiprivate connection and will run a site-to-site VPN. Instead, the uninformed client opens the whole network to the cloud.
It's not that organisations shouldn't play with big kids' toys, but they need to be aware of their complexity. Traffic problems are not unique to MPLS, but its presentation and function make it easy to mistake for a VPN. A toaster oven is not the same thing as a modular food-heating unit, and a pair of MPLS routers are not plug-and-play access points.
Three precautions
Anyone in the market ought to consider at least these three simple precautions when MPLS is in play:
Jon Espenschied has been at play in the security industry for enough years to become enthusiastic, blasé, cynical, jaded, content and enthusiastic again. He is currently a senior security consultant in Seattle, where his advice has been ignored by CEOs, auditors and sysadmins alike.
.gif)
SANs tuned for virtualisation
Add your commentComments