Internet-based SD-WAN has an authentication problem. In fact, Internet-based SD-WAN is an authentication problem. Let's see what that problem is, and how to overcome it.
SD-WAN is a broad term used for a variety of alternatives to traditional fix-point wide-area networking (WAN) technologies, like T-1 lines or the more modern multi-protocol labeling switching (MPLS). Those traditional WANs are private networks provisioned through one or more carriers or telcos. They are reliable and secure, but are also very expensive, slow to provision and difficult to change. Those traditional WANs don't offer good solutions for short-term or mobile connections, but are excellent for tying together corporate sites, or for linking a data center to a cloud provider.
By contrast, software-defined WANs -- SD-WANs -- are everything that traditional WANs aren't.
SD-WANs leverage standard Internet connections at one or both ends; those might be based on phone lines (DSL), cable modems, cellular modems (4G or 5G), or even high-speed leased lines. Sometimes the SD-WAN terminates in a traditional data center, but increasingly, the link goes directly to a cloud service provider (CSP) to tap into dedicated or virtual servers.
What are SD-WANs used for?
Just about everything that a traditional WAN could be used for in the enterprise. For instance, tying a branch office to a central office's data center. Another benefit is that it can be provisioned as fast as you can get Internet service to a specific location, which can be instant if using cellular modems, or a matter of days of DSL or cable. Additionally, there's no need for dedicated WAN customer premises equipment (CPE), like you would need for MPLS or T-1 circuits. Finally, there's improved quality of service over a traditional Internet link, especially when SD-WANs aggregate multiple connections to add quality of service (QoS) with service-level guarantees.
What about security? That's the issue that SD-WAN providers are constantly trying to address with customers. Nobody truly trusts traffic going over the public Internet, but that's exactly what many SD-WAN providers do for at least part of the journey.
Encryption and authentication
There are two basic ways of ensuring that traffic going over the Internet remains private: Strong encryption and strong authentication. The first is a strength of SD-WANs in general; the other is a concern.
Nearly every SD-WAN provider touts the quality of its encryption: 256-bit, 512-bit, whatever. Whether you call it "military grade" or not, that's more than adequate for most purposes, unless your data is sufficiently valuable that someone is going to try to break your encryption.
Authentication is trickier, because both parties need to trust each other.
A bank kiosk connected through SD-WAN technology to the bank data center needs to know, absolutely, that it's really talking to the bank, and not a faker. The bank needs to know, absolutely, that it's talking to a genuine kiosk.
A challenge, however, with some SD-WAN solutions is that a third party is handling the authentications: the SD-WAN provider itself.
That's due to the architecture: The kiosk uses the public Internet to access not the bank data center but the SD-WAN provider's local node. It authenticates to that node and routes its traffic through that node. The bank's data center or cloud-hosted servers similarly authenticate to the SD-WAN provider. The SD-WAN provider vouches for everyone and establishes the bidirectional link.
The data is encrypted, so there's not a real worry that the SD-WAN provider is listening into confidential communications. However, the bank has outsourced its authentication process to the SD-WAN provider. That concerns me and should concern you as well -- unless there's zero trust in the SD-WAN itself.
And that's what I recommend. Despite what the vendors promise, don't trust it.
Use SD-WAN, by all means.
It's significantly less expensive than any traditional WAN technology, in some cases by orders of magnitude. It's hugely faster to provision and move than MPLS, especially when the SD-WAN needs to span multiple countries or carriers. It's easier to manage, thanks to web-based administrative tools. And it can offer superior QoS over vanilla Internet connections as well -- some SD-WAN providers have done an excellent job with compression and load-balancing.
Use the SD-WAN to establish an authenticated and encrypted link -- and once that link is established, use virtual private network technology, specifically, not one offered by the SD-WAN provider, to authenticate an end-to-end secure communication that's re-encrypted by the VPN.
Does that add complexity? You bet. But I wouldn't have it any other way.
— Alan Zeichick is principal analyst at Camden Associates, a technology consultancy in Phoenix, Arizona, specializing in enterprise networking, cybersecurity, and software development. Follow him @zeichick.