So if a company has a site-to-site VPN over the internet, it’s going to be encrypted, obviously… but why is it that this has not usually been the case for MPLS? In either situation, traffic will be traversing through a third party’s network (a service provider)… and isn’t the whole idea that you don’t want these third parties to be able to see/alter your traffic?
The internet would pose a greater risk, of course (with traffic traversing many different service providers as opposed to just one… potential for BGP shenanigans too)… but, the risk still seems to be there with MPLS.
Because they have a commercial relationship and legal contract with the entity that could potentially spy on them. They know who they are trough reputation, and can have some confidence that their business model is legitimate and not based on stealing customer data.
Yes there are still risks, but it’s not the same as if the data flows through unknown third-party networks.
While that’s definitely true today, trends (and regulations) are driving more and more companies towards encryption over MPLS, mainly due to SD-WAN, but you might see others running GETVPN or something similar.
Cost and threat model.
With an L2/L3VPN, you’re exposed to your provider, and to threat actors who are big enough and ugly enough to infiltrate your provider, or physically attack your provider’s infrastructure.
With VPNs over the internet, you’re exposed to everyone, more or less.
So if you’re small enough not to be worried about targeted attacks by state level actors or really major threat actors, trusting your provider not to mess with your traffic may be a rational choice, since it allows you to avoid the financial and operational costs of sticking encryptors in your data path.
Isn’t Macsec a thing in MPLS? I am pretty sure that we are using this
One thing to keep in mind is something like a site-to-site vpn offers tunnel endpoint authentication in addition to dataplane encryption. This is important if your exposing tunnel endpoints to the internet. You don’t have this issue with a mpls circuit.
I think you could ask a lot of shops your question and the result would be they actually care about tunnel endpoint authentication than encryption when you dig into it. They probably won’t admit it though.
I’ve advocated VPN over MPLS for years, and people look at me like I’m insane.
This after I’ve seen other customers’ traffic on MPLS because the carrier messed up the routing…
Zero trust. Use MAC-sec for L2 MPLS and DMVPN for L3 MPLS. Each are trivial to implement and have next to zero overhead on modern switches.
Risk is there, yes, but considerably less so.
Safe way would be encryption. Some people don’t have security in mind though.
If you have a use case or problem statement requiring it, sure. If not, I would pass.
typically because they are label switched and mostly only the access provider can see the traffic, IE the traffic never touches 3rd party devices. Adding full mesh ipsec adds a whole layer of complexity and overheard as well. We recently added SD-wan to our environment and kept our hosted MPLS circuits for higher SLA traffic. the sdwan builds IPsec tunnels across the MPLS for us, as well as our public internet circuits. Our provider also drops some SIP trunks into the mpls for us. so unfortunatly traffic from our VOIP endpoints has to travel into the MPLS outside of Sd-wan unencrypted for those specific endpoints.
You may be looking at this from the consumer perspective. The benefit of MPLS to the provider is that it reduces costs. That’s it. That’s why it’s the predominant technology for multiservice backbones.
Before MPLS providers had to carve out new backbones for every distinct service. Internet was shared and public. But the first “private” network utilizing RFC1918 addressing required a new backbone, either via new physical point to point infrastructure, Frame Relay, or ATM PVCs.
MPLS was revolutionary in that it converged all services and multiple service types over a single backbone. MPLS enables a single forwarding interface to transmit internet, private ip, and private layer 2 traffic for one or more tenants.
MPLS VPNs aren’t encrypted (without additional value adds) because MPLS VPNs aren’t VPNs in the way you’re thinking of them. If you conceptualize it more like a VLAN, you could ask the same question. Why doesn’t my switch manufacturer encrypt every new VLAN I make? The answer is the same for both; because that’s wrong headed.
What hardware would you select to encrypt and decrypt the redundant 10G MPLS endpoints between 4 data centers and how much will that cost? You will need 12 pairs of them.
What latency would the 2 additional steps of block buffering then encrypt/decrypt add?
edit: added ‘pairs’ 12 links are needed.
Same reason you dont encrypt your landline telephone calls between offices.
On a similar topic can someone give me a real life scenario of unencrypted traffic over the internet resulting in major issues/breaches etc for an org? Is this something that might be a bigger concern outside of North America (today at least)? Let’s say a wfh staff has their traffic to HO running over a GRE tunnel.
I mean, would you encrypt your traffic over point-to-point leased line private circuit?
I would love to hear anyone who leverages encryption over a fully meshed worldwide MPLS network. Mostly because the cost of doing that would become astronomical at some point due to the speeds involved, not to mention the complexity of that design.
I’m sure someone is doing it or has attempted it. I’m just unsure how that works at scale.
if you have a security mindset then you should always encrypt your traffic when its traversing a unknown/untrusted medium like internet or service provider leased clouds.
sure the provider might have segmentation with gre tunnels, vrf’s, vlans, vxlans within their infrastructure but if you always think about the worst case scenario which is a data breach then encryption it is!
now the biggest thing to security is a budget, your network is only as secure as its weakest link and if mgmt bought a crummy ipsec headend that is always needing patching but it was cheap…well there you go thats your weakest link.
MTU might be of an issue. You have the Ethernet packet maximum length of 1500 bytes. On top the switching labels that slightly reduce the MTU. When you introduce VPNs they also add their headers. This further reduces the effective MTU. That will cause fragmentation of packets which means delay. Time sensitive protocols (video/voice) will be impacted
Besides malicious actions, there’s also the possibility of a typo by one of your ISP’s engineers. It can happen.