When it comes to the subject of SD-WAN security, there are number of views and viewpoints – SD-WAN security typically will relate to the following;
Security of the Edge nodes and the control & management components, with questions often around security standards and certifications supported (like FIPS 140.2, etc.).
What Firewall features and functionalities do the Edge nodes and other components support (i.e. standard F/W vs. NGFW, IDS/IPS functionalities, etc.)
Security of the overall SD-WAN Overlay network utilizing any type of transport vs. currently deployed Private Networks, like MPLS VPN’s.
Cloud connectivity security enhancement and flexibility vs. “traditional connectivity model”.
All the above security aspects are very important considerations for the design and delivery of a secure SD-WAN network. This post will concentrate on the last 2 items from the list.
The best way to understand how secure SD-WAN is, and what the security enhancements the Overlay network provides, is to compare it directly with MPLS VPNs (currently accepted as a Private Network standard).
To understand how “secure and private” MPLS/VPN services are, and how they compare to SD-WAN, we need first to understand how both technologies work and are being implemented.
How an MPLS/VPN service works
The MPLS/VPN (L2 or L3) service is based on MPLS (Multi-Protocol Label switching) technology, where the PE (Provider Edge) Egress router assigns several Labels to each packet, after which they are “switched” across the core (P-Provider routers) until they reach the end destination, being the Ingress PE router.
The PE’s connect each Customer Edge (CE) router and provide a separate “private” routing table for each customer, known as a VRF (Virtual Routing and Forwarding).
The CE and PE are running routing protocols (such as BGP, OSPF, etc.) between them to deliver the routing updates into the VRF’s.
The correct “redistribution” of the routing information is based on route tagging (RT’s and RD’s).
The graphic below represents a high-level view of a typical Service Provider network:
SP MPLS/VPN High Level Architecture
As you can see a single PE router can provide connectivity and services for:
Corporate Private network
How an SD-WAN works
An SD-WAN securely connects users (i.e. branches/sites) to any application, whether hosted in the data centre or in the cloud, across any WAN transport service including broadband internet services, and brings application awareness and application control to the network.
The SD-WAN network builds the “Overlay” network based on IPSec technology. An Overlay network is based on many P2P IPSec tunnels which use the MPLS/VPN, Internet, and other connectivity options only as a transport. Traffic goes from one site to the other site fully encrypted, where the underlay transport and transport service providers are completely unaware of the IP addresses, routing, and application data that travel across.
SD-WAN High Level Architecture
Encryption Key exchange/rotation at regular intervals of 10-20 minutes on every tunnel ensures very strong security. Further enhancement options such Packet Encryption Headers and Packet Authentication can provide increased security measures, meaning Packet integrity can be guaranteed.
Achieving all of this using the current MPLS Private networks is virtually impossible.
Security Compared (MPLS/VPN vs SD-WAN)
MPLS/VPN’s are shared networks and not private
Each customer’s traffic is logically segmented (or tagged) by the MPLS labels, but the labels are used only for forwarding decisions. Traffic from thousands of different customers and users (including traffic from other carriers and the Internet) traverse a common set of backbone routers. In reality, the Provider Edge (PE) router is a “shared platform” where different customers, including Internet customers, are connected.
Note: some outdated Service Provider networks can even run Full Internet tables as part of the Router global table.
The Service provider backbones are “shared” between the Private VPN and Internet customers’ traffic without any mechanism to separate or segment the traffic. The only option is to tag the traffic from a transport point of view.
Customer Edge (CE) routers are assigned to individual customers, but Provider Edge (PE) and Provider backbone (P) routers are shared. In other words, only the router in your office is “private” – the very next router your traffic hits (and all the routers after it) are shared by multiple users.
When an SD-WAN Overlay uses MPLS/VPN’s as a transport, the traffic is fully encrypted, therefore using the “shared” Provide backbone does not present any significant security concerns.
SD-WAN solutions by default encrypt all the traffic (Control and Data) being sent via the Overlay network. By comparison, an MPLS/VPN service provides no option for traffic encryption, leaving the end users or the applications needing to provide their own if there is a security requirement to do so.
Data traversing the carrier’s common infrastructure is in clear text, therefore your security is contingent on the security of your carrier. Taking into consideration standards like GDPR for example, traffic encryption “in-transit” is almost compulsory, which cannot be supported by MPLS/VPNs.
One other potential security consideration on the MPLS/VPN network is the ability of the Service Provider to implement “port mirroring”, which can replicate customer traffic and then send it to a tool like Wireshark for example. In practice, this can be done by any L1 support person, and the customer will have no method to detect or prevent it or understand if their traffic has been “highjacked”.
The question here is whether you trust Service Providers to monitor if someone is sniffing or replicating your data, and would they tell you about it? Surely a better option is to just secure you data with SD-WAN and not be exposed to any of the above.
Customer routing and routing tables
With SD-WAN the Overlay network makes the customers’ subnets and routing information completely unviewable from the Service/transport Providers point of view.
For an MPLS/VPN service to “function” properly from a routing prospective, the sites’ subnets have to be in the VRF’s. This means that all customers’ subnets must be exchanged with the Service Provider PE routers, therefore the Service Provider in some respects “owns and manages” the customer routing (routes and subnets).
The exposure of the customers’ subnets, routing information, and the potential for Service Provider misconfigurations which can lead to one customers’ routes going into another customers’ VRF, emphasises the point that MPLS/VPN services are potentially vulnerable to many security issues.
Do you trust the Service Providers to ensure there are no OS bugs in their infrastructure, to not misconfigure routes and send your traffic to another customer, to ensure they are secure against all known WAN attack vectors and long list of BGP bugs?
Again, surely a better option is to just secure your data with SD-WAN and not be exposed to any of the above.
What is Network Segmentation and why is a such a big problem?
Network segmentation on the LAN is well known and has been widely implemented for many years based on VLAN’s, communicating via routers or Firewalls to guarantee security and integrity.
Unfortunately, once the traffic “leaves” the Branch, MPLS/VPN’s are not able to “protect” the VLANs or the Network segments End-to-End. Traffic from Branch-1 sent by the Ingress CE is “mixed” with other traffic on the “shared” MPLS infrastructure, and then received by the Egress CE at Branch-2 as traffic that “belongs to Branch-1”. Customers must introduce Firewalls to reclassify the traffic again and then send to the right VLAN’s or segments.
With SD-WAN, Customer VLAN’s (HR, Production, Test, etc.) as well as Partners/Suppliers and Guest Wi-Fi VLAN’s can be delivered across the Overlay network in complete separation. Branch and Head Office VLAN’s can be mapped (One to One) to the VPN’s and distributed across the Overlay network securely, and in full and complete separation even using different topologies (full meshed, Hub and Spoke, etc.).
There are many use cases for segmentation
An enterprise wants to keep different lines of business separate (for example, for security or audit reasons). Very useful in case of M&A.
The IT department wants to keep authenticated users separate from guest users.
A retail store wants to separate video surveillance traffic from transactional traffic.
An enterprise wants to give business partners selective access only to some portions of the network.
A service or business needs to enforce regulatory compliance, such as compliance with HIPAA, the U.S. Health Insurance Portability and Accountability Act, or with the Payment Card Industry (PCI) security standards.
A service provider wants to provide VPN services to its medium-sized enterprises.
An enterprise wants to set up a trial run of new service and wants to use a cloud service for development and system test.
In SD-WAN architecture, an Organisation benefits from end-to-end encryption across the entire network, including the Internet. All devices and endpoints are completely authenticated, thanks to a scalable key-exchange functionality and software-defined security. All communication between the main office and branch offices is secure, as is communication to and from the cloud – the key highlights are:
End to End Encryption over any transport (Encryption in transit)
Network Segmentation support and easy implementation
Customer IP Subnets and routing is completely hidden from the Service providers
Support and easy implementation of Cloud security. Branches and remote users can take full advantage form the CSP services.
Cookies are small files containing information that enables a website to recognise you. They’re downloaded to the device you use when you visit a website and sent back to that website each time you re-visit, or sent to another website that recognises the same cookie.
Strictly necessary cookies include session cookies and persistent cookies. Session cookies keep track of your current visit and how you navigate the site. They only last for the duration of your visit and are deleted from your device when you close your Internet browser. Persistent cookies last after you’ve closed your Internet browser and enable our website to recognise you as a repeat visitor and remember your actions and preferences when you return.
These cookies are strictly necessary and should always be enabled so we can save your preferences for cookie settings.
Third Party Cookies
Third party cookies include performance cookies and targeting cookies. Performance cookies collect information about how you use a website, e.g. which pages you go to most often, and if you get error messages from web pages. These cookies don’t collect information that identifies you personally as a visitor, although they might collect the IP address of the device you use to access the site. Targeting cookies collect information about your browsing habits. They are usually placed by advertising networks such as Google. The cookies remember that you have visited a website and this information is shared with other organisations such as media publishers.
Keeping these cookies enabled helps us to improve our website and display content that is more relevant to you and your interests across the Google content network.
Please enable Strictly Necessary Cookies first so that we can save your preferences!