The ‘MPLS Is A Private Network’ Debate

This discussion item came up during recertification training last week.  It caused a lot of debate from the QSAs in the room with no final decision on who held the correct point of view.

The PCI SSC, participating organizations and the card brands have stated that MPLS (aka, Multiprotocol Label Switching) is a private network, meaning that cardholder data transmitted over an MPLS network does not have to be encrypted.  What was debated was the correctness of that decision.  Where I come down on this issue is that MPLS on its face is not necessarily as private as one might think.

Unlike previous telecommunication solutions such as frame relay and ATM, MPLS is Internet Protocol (IP) aware.  By definition, “When packets enter a MPLS-based network, Label Edge Routers (LERs) give them a label (identifier). These labels not only contain information based on the routing table entry (i.e., destination, bandwidth, delay, and other metrics), but also refer to the IP header field (source IP address), Layer 4 socket number information, and differentiated service. Once this classification is complete and mapped, different packets are assigned to corresponding Labeled Switch Paths (LSPs), where Label Switch Routers (LSRs) place outgoing labels on the packets.”  The key here is that MPLS uses IP header information in order to properly route traffic.  In essence, MPLS is no different from layer 3 IP switching/routing using VLANs on obviously a much larger scale.

Since MPLS is protocol aware, it allows carriers such as AT&T, Verizon, BT and the like to automatically reroute packets to avoid network congestion, outages and other issues that may affect network performance.  Not only can the carriers reroute packets on their own networks, but they can also reroute packets onto other carrier’s MPLS networks if necessary.  And best of all, this occurs automatically based on how your MPLS network is defined.

Carriers will point to IEEE 802.1q for securing MPLS networks.  802.1q is the definition for the tagging of VLAN traffic to separate traffic on the same VLAN.  While in theory the standard does keep the traffic separated even on the same VLAN, it also can be intercepted with the right tools.  So, security is in the eye of the beholder.

Contracts for MPLS service typically include clauses that indicate that the MPLS network will be private, meaning that one customer cannot get to another customer’s network and visa versa.  But here is a potential glitch.  If a carrier reroutes your MPLS traffic to another carrier’s MPLS network for any reason, there is likely no guarantee that your traffic will remain private.

So now that I have described what MPLS is and how it operates, what impact does or can it have on an organization’s PCI compliance? Well, it depends.

The primary point is that an organization’s network traffic is in the clear on an MPLS network, meaning that the carrier and anyone else that has access to the organization’s network can read packets on the MPLS network.  Based on the architecture of MPLS, there are potential risks that the carrier could misconfigure the MPLS network and cause packets to cross to a path.  While this sort of mistake is typically noticeable and rare, it has been known to happened, so it is not totally out of the realm of possibility.  In addition, IP spoofing and similar attacks can be used to penetrate the 802.1q protocol, so it is not an absolute assurance that your traffic will stay secure over the carrier’s network.

Carriers operate multiple customer MPLS networks using large layer 3 switches and many VLANs.  Traffic from multiple customers may be aggregated on a single VLAN or over their own individual VLAN.  Regardless, VLAN access controls need to be understood and properly managed and maintained just like on your own network.  Under MPLS, your carrier is just putting you into one or more VLANs to move your data from location to location.  Under network segmentation rules, there needs to be proper controls in place to ensure that VLANs and access to them a truly separated.  Remember, it is not just your data streams; it is many customers data streams being managed and separated.  Under MPLS, I would argue that the carrier’s controls in this area should also be assessed for PCI compliance as well as the customer’s because the carrier’s network is just and extension of the customer’s.

Since the carrier is just an extension of the customer’s network, the carrier needs to be made aware of PCI or other sensitive network traffic so that they can take appropriate measures to ensure the security of the data stream.  This may include having the carrier commit to ensuring the security of the data stream by segregating it from other customers’ traffic and not rerouting it to another carrier’s network.  If the carrier is aware of PCI data traffic, the carrier is also responsible for complying with PCI DSS requirements to ensure that traffic maintains its privacy and security.

In response to the risks presented by MPLS, a lot of organizations just encrypt their network traffic.  However, encryption defeats the point of MPLS because once the data stream is encrypted, MPLS can no longer have access to the IP headers.  There is currently an IEEE working group that is developing a new encryption standard that will make IP packet headers readable while encrypting the packet’s payload, thus allowing MPLS to still route packets without having access to the data contained in those packets.  When this new encryption standard will be released is anyone’s guess, but there is impetuous to get it agreed to quickly so that MPLS can be better secured.

The bottom line is that MPLS may or may not be private.  It all depends on how the carrier implements it.  As a customer, I would recommend that you discuss your network security and privacy requirements in detail with your carrier so that they can accommodate your requirements and understand their potential obligations.  Do not just accept their assurances that MPLS is private.  In the end, if the carrier cannot ensure the security and privacy of your data, then MPLS is likely not your networking solution.


The PCI SSC issued an FAQ (#1045) in May 2014 on this topic.  To quote the Council:

Is MPLS considered a private or public network when transmitting cardholder data?

Whether an MPLS network can be considered a private network is dependent upon the specific provider and configuration of that network. The implementation would need to be evaluated to determine whether the MPLS network provides exposure to the Internet or other untrusted networks, before concluding whether the MPLS network can be considered private. If the MPLS network contains publically-accessible IP addresses or otherwise provides exposure to the Internet (for example, if an edge router has an Internet port), then it may need to be considered an “untrusted” or a public network.

If the MPLS network is determined to be private, transmissions of cardholder data over that network would not need to be encrypted per PCI DSS Requirement 4.1.  However, if there are points of exposure to the Internet or it is a shared connection, the MPLS network could be considered as untrusted or public, and Requirement 4.1 would apply.

MPLS networks that have been verified as being private are still in scope for PCI DSS, and, as with all private networks that are in scope, the MPLS network and associated devices would need to meet the applicable PCI DSS requirements.



20 Responses to “The ‘MPLS Is A Private Network’ Debate”

  1. 1 Robert Smith
    August 28, 2013 at 10:47 AM

    Simply use Transit Layer Security (TLS/SSL) to transmit packets over the MPLS network that need it. The IP Headers are available in those packets and MPLS will be fine. It’s not like hiding your internal subnets is necessary because every hacker on the planet already knows what RFC1918 is.

    • August 30, 2013 at 5:58 AM

      The trouble with TLS/SSL is the certificates. You really should not use self-signed certificates. Going to VeriSign or some other recognized/reliable certificate authority (CA) costs money and can get expensive depending on the number of locations (to be safe, each location should have it’s own certificate). I’ve seen too many implementations of TLS/SSL using self-signed certificates where the in-house CA is not as secure as it should be. Meaning that obtaining the self-signed certificates and breaking the encryption is a piece of cake.

      IPsec is the other encryption option, but that obscures the IP headers by placing the traffic in a “wrapper”. As a result, MPLS cannot “automagically” reroute traffic in the event it needs to change a circuit’s path without breaking the IPsec “tunnel”.

  2. March 27, 2012 at 9:31 AM

    I know this is an older thread but I think it’s still relevant. First, I’d like to comment that much of the data about MPLS not being secure is valid. So is the point that was made that no network is secure regardless of which layer is used for multiplexing. I can go into my frame relay switch and put an incorrect PVC in there and possibly route frames to the wrong customer. If they are both using IP (likely) then there is a chance they could intercept data.

    PCIGuru suggests that MPLS can be implemented properly or not. I don’t think that’s true. Sure you can put access controls and audit provisioning systems but that isn’t any guarantee. The truth is that the packets are not encrypted on the wire and they can be read without much effort if they end up in the wrong place. I don’t know of any carrier that could assert anything different.

    I have always been of the mindset that encryption should be pushed up the stack rather than implemented at the network layer. The idea of the network layer is to get things where they need to go so that should be the focus. I see that someone mentioned SSL VPN which can work well on an application basis when needed without encumbering the network layer with unnecessary cycles spent encrypting data which doesn’t require it or need it.

    A working group was mentioned that addresses encryption of MPLS payloads but I wasn’t able to find much on that with a quick search so I’m not sure the status. I am sure though that no carriers I know of do it presently.

    • March 28, 2012 at 4:00 AM

      The IEEE had/has a standards group developing an encryption standard for MPLS that would allow the packet payloads to be encrypted but not encrypt the routing information. Current protocols like IPSec work over MPLS, but in the event of rerouting, the IPSec tunnel drops and has to be re-established.

  3. 5 Jeremy
    April 15, 2011 at 8:06 PM

    ..the QSA would need to review the specific network provider and configuration details and determine whether the network could expose data to the Internet or other untrusted networks.

    Can you please explain what that would look like and how a QSA would be able to determine this? My guess is that they would not be able to as QSA are not going to be given access or information necessary from AT&T, Verizon, Sprint, etc to make this determination. As a result, the final decision is always going to be “public for the purposes of Requirement 4.1”

  4. September 7, 2010 at 12:16 PM

    This is a great article as it is very objective. MPLS is great for being private and for offering a Class of Service (COS) especially for time sensitive applications like Voice and Video. However even these two applications are in need of being secured as well as sensitive credit card information. I recently had to recommend a solution to a large global Financial Services client who recently needed a solution like the one what you mention may be proposed to the IEEE… being able to encrypt at Layer 4 while maintaining the header information while actually protecting the payload by encrypting (256 AES )it. I found only one company that was able to do it with the added benefit of decreasing the latency that an IPSEC solution would introduce. The company is called CipherOptics which is based in Raleigh, NC

  5. May 12, 2010 at 4:24 PM

    One could argue that no network that leaves a customer’s premises to the provider is a private network, whether voice, frame relay, or dedicated fiber–it’s all subject to potential interception or misrouting due to configuration error. It makes more sense to insist that cardholder data be encrypted in transit over a WAN connection than to bring entire telecommunication provider infrastructure and its operational practices into scope for a PCI audit.

  6. 8 Ankur
    April 19, 2010 at 11:41 AM

    “The PCI SSC, participating organizations and the card brands have stated that MPLS (aka, Multiprotocol Label Switching) is a private network, meaning that cardholder data transmitted over an MPLS network does not have to be encrypted.”

    I have not come across a definitive decision from the council on MPLS private status. Please can you confirm if the council or card brands have issued such statement.

    • April 19, 2010 at 12:36 PM

      My point with this post is to explain to people that the PCI SSC and the card brands are uninformed regarding MPLS. Properly implemented, MPLS can be considered private. However, not all MPLS is properly implemented and, as a result, is NOT private. It is a sore subject with me as whenever this topic is brought up, the telecom carriers tell the PCI SCC that they NEVER implement MPLS in such ways. However, in talking to their sales people and technicians as well as reviewing contracts, we are told a different story.

    • May 27, 2010 at 5:59 AM

      On the PCI SSC FAQ, article # 8705, is where the PCI SSC discusses whether or not MPLS is private.

  7. 11 John Cheng
    April 16, 2010 at 12:29 PM

    Wait, correct me if I’m wrong – I’m responding mostly to further understanding. In this case — encrypting MPLS traffic in a way that let’s carriers QoS it they way they want — an SSL-based VPN like OpenVPN would be the right tool for the job. It’s at the app layer so that will let carriers do what they want?

    • April 17, 2010 at 10:25 AM

      Agreed. An SSL VPN solution does encrypt things above the transport layer and allows an MPLS provider to read the packet headers. I was referencing IPSec VPNs in regards to what the IEEE is reworking.

      SSL VPNs were developed to provide a more flexible, yet secure solution for instances where you need security but do not know where the connection will be coming from. The problem with most SSL VPNs is that security is one way in that only the termination connection point is authenticated by their certificate. The initiator of the SSL VPN session is usually only authenticated with a user identifier and a password. Not that you cannot add certificates at the initiator end of an SSL VPN, but that is not what it was really designed.

      IPSec is used by most organizations in instances where the secure connection is always expected from a particular IP. In addition to a user identifier and password, IPSec VPNs usually have certificates at both ends to further identify and confirm that the connection is correct. Another added advantage is that an IPSec connection requires particular software at both ends, so it is less likely to be successfully attacked.

  8. 13 John Cheng
    April 16, 2010 at 8:59 AM

    Might as well encrypt it yourself with say, IPSec or OpenVPN, and be done with it. Is this not similar to the argument of people not setting up strong passwords (or any password at all) for internal systems that are firewalled off?

    • April 16, 2010 at 9:40 AM

      While encryption is an option, it defeats one the primary purposes of using MPLS, redirection of traffic by the carrier based on traffic congestion or path breaks. The problem is that a lot of telecommunications sales people pitch the “self healing” aspects of MPLS very heavily to influence non-technical types in buying MPLS service. However, the only way the carrier can accomplish redirection is if they can read the packet headers. Obviously, if you have encapsulated your data stream in a VPN tunnel, the carrier cannot redirect your traffic. You must then re-establish your connectivity and VPN connection. Meanwhile, your bosses’, bosses’, boss is PO’d because the automatic “self healing” aspects do not work and it’s your fault, not the fact that you are secure but that you have defeated the feature that person based their decision upon.

      That is why the IEEE is working on a new MPLS VPN standard that will allow the payload of packets to be encrypted, but the message headers will still be accessible for redirection.

      • 15 Jesse Okerlund
        November 11, 2010 at 5:06 PM

        Many of the technical details about carrier grade MPLS networks in this article are incorrect.

        1) Carrier MPLS networks DO NOT re-route traffic to each other during outages or times of congestion. ATT NEVER would send MPLS traffic to Verizon, and so on.

        1a) The only time that a carrier would transition customer traffic to another MPLS carrier would be for pre-determined foot print expansion. Example: Using a in-country provider in mainland China to extend a customer’s private MPLS network. These configurations are pre-determined, pre-negotiated and pre-configured.

        2) Once traffic enters a carrier MPLS network, the IP headers are not visible and are NOT used for routing decisions, including redudancy and traffic re-routing. The customer packets, including IP headers, are encapsulated in the MPLS label. You can IPSEC encrypt traffic through a carrier MPLS network and it will re-route seamlessly around outages, as would any other un-encrypted traffic. This is standard across all major MPLS carriers.

      • November 11, 2010 at 8:04 PM

        I respectfully disagree with a few of your comments.

        1) Many contracts that I have reviewed indicate that re-routing of traffic can occur and there is no guarantee of when or how this occurs. It is all to the carrier’s discretion. This is done to ensure that the customer’s SLA is maintained. I agree that AT&T would not necessarily want to re-route traffic to another carrier. But, all carriers have legal agreements for major incidents where service needs to be uninterrupted. Not that a merchant would have access to such services. However, hospitals, government facilities and similar critical infrastructure locations would have access to such services.

        The bottom line is that all organizations need to fully explain their telecommunication requirements as well as security and privacy requirements to their carrier to ensure that the carrier constructs the MPLS network appropriately. MPLS is not Frame Relay or other, traditional circuitry where the engineering does not effect the privacy or security of the network. If the carrier does not have this knowledge, then who knows how the network will be engineered or if it will be secure.

        1a) Agreed. However this has been true for services such as Frame Relay, point-to-point and is not something new for MPLS.

        2) Yes, there is an additional MPLS envelope that wraps the traffic for routing through the MPLS network. However, this encapsulation as you call it does not provide any level of security, it is strictly for MPLS routing. IPSec or any other VPN technology using IPv4 defeats the benefits of MPLS as the MPLS endpoint has no access to the original header information except at establishment of the tunnel. As a result, while you can establish an IPv4 VPN tunnel over an MPLS network, if any re-routing occurs, the VPN tunnel will collapse and the connection lost. I know this to be true because I have seen this happen first hand during network testing. It is my understanding from my serious network engineering friends that IPSec over MPLS and re-routing only works with IPv6. Since only a very, very small handful of my clients are running IPv6, I don’t see this as a feasible solution.

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 )

Connecting to %s

Welcome to the PCI Guru blog. The PCI Guru reserves the right to censor comments as they see fit. Sales people beware! This is not a place to push your goods and services.

April 2009

%d bloggers like this: