At this year’s PCI Community Meeting the issue of whether or not MPLS is private came up again. I was in one of the Open Forums when the topic of MPLS and whether it was private came up. This is not a new issue as it has come up before and I have also discussed it in two previous postings.
The reason it came up was that a former network engineer wanted to understand from the PCI SSC technical representatives how they justify MPLS being private. What ensued was an excellent discussion regarding the architecture of MPLS and the PCI SSC’s rationale for considering it private. For those of you not familiar with MPLS, in a nutshell, MPLS is just a larger IP network used to route customers’ network traffic over an IP network.
What the network engineer brought up was the fact that an MPLS network is no different from any other IP network with spanning tree and other architectural issues that hardly make MPLS private. They also brought up the fact that even with Frame Relay and other older telephony technologies, those circuits are also being sent over MPLS by the carriers. Given that at some point MPLS traffic has to technically co-mingle with other customers’ network traffic, how can the PCI SSC stick to its claim that MPLS is private? The answer provided was a bit disconcerting to some in the room. But for those of us with an understanding of the engineering issues related to MPLS, it was expected.
The group present was told that MPLS is considered private because the carriers consider it private and it is sold as a private network service. A lot of people in the room gasped and the next question asked was, “Isn’t that a lot like saying trust me?” As the PCI SSC representative continued to explain, there really is not another way to work with MPLS.
Is it possible to breach data in an MPLS network? Yes. Can it be easily accomplished? Not really. The attacker would have to have access to a carrier’s core switch and have a port or two in promiscuous mode to gather all of the packets flowing through that switch. As a result, organizations need to accept the risk presented by MPLS. The unfortunate fact is that most organizations do not even know there is a risk however slight it might be. At the end of this discussion, the PCI SSC person recommended that, if an organization is concerned about the privacy of MPLS, then they should encrypt their data over the MPLS network.
So, there you are. If you think MPLS is not private, then encrypt your data. Hopefully this issue is resolved.
Other relevant posts:
One could raise exactly the same concerns about frame relay, ATM, and even POTS–it’s all shared, multitenant provider infrastructure, where either a malicious insider, a configuration error, or a lawful intercept order could result in interception of an unencrypted communication by a third party. Correctly configured MPLS VPNs will logically segregate customer traffic so that customers don’t see each other’s traffic.
Technically, the backbone infrastructure of all telecommunication carriers is VoIP at some point, so, yes, I would have to agree with you to a certain extent. That said, contractually, the telecommunications carriers are legally obligated to ensure that POTS, Frame Relay and ATM are logically separate even though today they can no longer ensure physical separation. Not that that is a control you should rely upon, but at least you have someone to sue.
There are still some backwater areas of the world where POTS, Frame Relay and ATM are still physically separate but those are getting fewer and farther between.
Perhaps, for once, the Council wanted to not require some unreasonable task. Rather than just admit that it’s giving a get-out-of-scope-free card to MPLS, it tries to tap dance around the issue. I personally would be ecstatic if the Council would state that certain things are out of scope because putting them in scope would be an unreasonable burden, compared to the low risk inherent in the technologies/architectures/etc.