An Update On The MPLS Privacy Debate

The MPLS private network discussion continues.

A lot of network administrators and carriers argue that MPLS networks are private because the PCI SSC says they are private.  As more and more organizations migrate from ATM and Frame Relay, this topic keeps coming up again and again lately.  Because of the push back from carriers and network administrators, I went back and re-read FAQ number 8705.

“In general, MPLS networks are considered “private” networks and do not require encryption. This, however, is dependent upon the specific provider and/or configuration. If the IP addresses are public and the MPLS network provides exposure to the Internet either through the LSR or other device (if the edge router has an Internet port) then it should be reviewed carefully as it is likely considered “untrusted”. The QSA should review the implementation and determine whether the IP addresses are public such that the MPLS network provides exposure to the Internet, before concluding that the MPLS network is considered private. If the QSA cannot gain that assurance, then the whole network should be in scope. The PCI SSC is not compiling a list of approved MPLS solutions nor do they have any plans to do so. This requirement for encrypted transmissions is intended to apply to transmissions outside of an internal network to an external third party, going over an open, public network; this requirement does not apply to transmissions over an internal network protected by external facing firewalls, since that is not considered a public network.”

Apparently, carriers and network administrators only read the first sentence of the FAQ and conveniently forget the next three sentences.  But it is those three sentences that document the criteria to determine whether or not an MPLS network is private.  The criteria a QSA is to use to evaluate an MPLS network’s privacy are:

  • How is the MPLS network configured?
  • Does the LSR come into direct contact with the Internet?

While these appear to be fairly simple questions to be answered, these questions are anything but simple or even easily answered.

The first question, how is the MPLS network configured is a problem for a lot of QSAs and network administrators as well as carriers.  MPLS is just a specialized IP network, so how the network is engineered drives just how private is private.  The problem with relying on IP addressing as the only criteria of whether or not an MPLS network is private is not proof positive.  I would argue that, even if the IP addressing on the MPLS network is RFC 1918 compliant, if the subnet is not the same as the network connecting to the network, then a QSA should look into the network to confirm that it is private.  This is particularly true if the addressing on the MPLS network is an ARIN registered address block belonging to the carrier.  Yes, such a network would be private for the carrier, but could be anything but private for the carrier’s customers’ traffic.

The second question is also not as straight forward to answer.  Just because private addressing is used on the MPLS network does not mean that it does not come into contact with the Internet or Internet traffic.  Unless you have visibility through the entire network and the rules used for that network, it is anyone’s guess as to whether or not it comes into contact with the Internet.

Of course all of this implies that the carrier is willing to show you their MPLS network configuration and share other information about their MPLS network.  But getting such a candid talk about a carrier’s network is sometimes anything but easy.  I have personally encountered carriers that refused to explain anything about their network and also refused to allow anyone to look at their LSR configurations.  As a result, we had no way to confirm or deny that the network was private.  To add insult to injury, I have been told by carriers that I was wrong in requesting to look into the configuration of their network and that this was not what the PCI SSC intended.  That said, I have also jumped through hoops to work out a way to confirm as best I could that the MPLS network was private.

MPLS is just an IP-based wide area network and because it uses IP, it can have a number of vulnerabilities just like IP networks.  Carriers use human beings to manage these networks and they are fallible just like our own employees.  Therefore, it is highly likely that mistakes will sometimes occur that will affect the privacy of the network.  I am guessing that once we have a breach in the MPLS cloud, MPLS will no longer be automatically considered private and encryption will be required.

And it is not just MPLS networks.  Most ATM and Frame Relay networks are routed over MPLS backbones by the carriers.  So just because you do not use MPLS does not mean that you are immune to the risks of MPLS.

In the end, we will have to rely on the statements and representations of the carrier as to whether or not the network is private.  Is this a good way to secure your organization?  It is as long as your carrier never causes a problem.


5 Responses to “An Update On The MPLS Privacy Debate”

  1. April 30, 2012 at 11:02 AM

    Clay Keller wrote: “I would submit that encrypted transmission of PAN data should be required over internal networks unless there is a compelling reason to do otherwise.”

    I agree, but this isn’t the only issue–if there is a cardholder environment that is open to the WAN, then the provider potentially has access to it, and if an MPLS configuration error were to, say, put another customer’s site into your internal network, that site would have access. So cardholder environments should not only be firewalled from the Internet, they should be firewalled from the rest of the internal network. With those two steps, the public or private question about MPLS becomes irrelevant.

    The FAQ answer’s focus on whether the IP addresses used are public or private IP space is something of a red herring–what is relevant is whether those addresses are reachable from the Internet without passing through a firewall first, not whether they are RFC 1918 addresses or allocated from public space.

    • April 30, 2012 at 4:22 PM

      “… what is relevant is whether those addresses are reachable from the Internet without passing through a firewall first …”

      Exactly the problem. With MPLS, whether or not RFC 1918 addressing is used is irrelevant. I have seen MPLS configurations with Internet routeable, “public” IP addresses assigned by ARIN to a carrier as well as configurations using 10.x.x.x and 172.16-31.x.x IP addresses (i.e., RFC 1918 compliant). Both are technically just as secure as the other as long as there is no path to/from the Internet. But that does not require a firewall as all you need is a properly configured router with no external network routes defined.

      The bottom line in this discussion of MPLS privacy is that you are relying on the carrier to ensure that privacy and whether that is a rational position for an organization to take. The risk is that a carrier technician makes a mistake on the routing of your circuit, accidentally makes a path to the Internet and the party is over. While that sort of accident seems far fetched, what I have seen happen is the technician fat fingers an IP address or mis-reads his work order for a route and that route ultimately leads to the Internet.

      This is why the PCI SSC and card brands are saying, if you feel MPLS presents a risk because of the co-mingling of network traffic, then encrypt your transmissions over MPLS. However, that is optional because MPLS is considered as private as ATM, Frame Relay and similar telecommunication transmission protocols.

  2. 3 Paul Powenski
    April 28, 2011 at 8:28 AM

    Great to see the wide range of MPLS issues being addressed. I have had similar experiences with carriers ( I was even working for one who refused to describe how the MPLS network was ‘secure’ ) to describe any specifics of their networks. Due to regulations in regions and fall back capabilities several carriers can be involved in transiting data across the network between areas. ATM and Frame relay at least have multiplexing technologies which split the data payload and is constantly changing the channelization due to the algorithm being used to transport the data. This at least provides some data obscuring facility. Reassembling a Frame or ATM data stream is much more difficult than IP packets. This is one of the key differences with MPLS and ATM the IP frame remains intact from source to destination and is much easier to decode than frame relay and ATM as the data travels across the network.

    There is the argument that the MPLS data is mux’d at various transport stages as well and this is correct BUT a considerable amount of data travelling around the core is not multiplexed. Reconfiguring a MPLS stub router, edge router, or creating a new mesh, stub, end point network connection has become vastly simplified with MPLS vs. ATM or frame relay which required more work.

    It is perplexing why the protocol implementers provide NO mechanism within the MPLS protocol or routing software to enforce registering each network segment so that the network could be validated by it’s registration reducing the need for home brewed router robots to constantly check configurations ensuring the integrity of the network is intact.

    If there was inherit measures within the MPLS protocol which ensures the ‘privacy’ is maintained by registration I would be much more emeanable to accepting MPLS is private.

    For me MPLS has a degree of privacy but is NOT PRIVATE.

  3. April 22, 2011 at 2:23 PM

    I would submit that encrypted transmission of PAN data should be required over internal networks unless there is a compelling reason to do otherwise. I think it is only a matter of time until that is required. I know the council has to focus on the big issues first.

    However, like you say, all it will take is to “have a breach in the MPLS cloud”. Then “MPLS will no longer be automatically considered private and encryption will be required.”

    Most of the US telecom carriers seem to do a pretty good job on their security and router configs, but I’ve seen international carriers that are very suspect..

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.


April 2011
« Mar   May »

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,774 other followers

%d bloggers like this: