Posts Tagged ‘technology

18
Apr
09

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.

UPDATE:

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.

 




Announcements

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.

Calendar

August 2021
M T W T F S S
 1
2345678
9101112131415
16171819202122
23242526272829
3031  

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

Join 2,418 other followers