Having been in the field of Information Technology for 30+ years, I continue to find it interesting that what looks like new technology is very seldom completely new, or in a lot of cases, even new at all. We’ve recently been looking at IoT, and how it’s similar to Industrial Controls and related technologies.
A similar thing can be said for SD-WAN, at least on the surface. (Anyone reading this remember Packeteer Technologies?) It’s also something that we’ve been doing for years (albeit, perhaps, with less finesse) as we replace and/or augment legacy high cost services like MPLS with lower cost, faster to deploy services like IPSec protected Internet. It’s also becoming the current technology trend of choice, and like most trends (like, say, IoT), implementing security and applying security related policies is only just now coming to the thought process.
By definition, Software Defined WAN is the use of software-based decision making to determine a desired forwarding path, as opposed to more traditional technologies like L3 routing and L2 forwarding. Like a lot of our security challenges, the issue here is caused by the substantial application-based overloading of TCP/80 and TCP/443 by the HTTP protocol, which prevents our ability to make any meaningful decisions at the lower level of the OSI networking model, where it’s actually easier. In fact, a lot of the SD-WAN implementations kind of look like a more focused deployment of OpenFlow and similar technologies.
Like any new technology, one of the best times to look at making a change is when your existing technologies are up for either renewal or replacement. For SD-WAN, this could be either for the hardware that has been deployed, or for the circuits that the hardware is connected to. The next consideration is, how disruptive a change are you willing to undertake? For example, if you are looking to replace a device that is distributed at many remote locations (that typically have little or no IT staff), maybe it’s a good time to look at consolidation, and include SD-WAN or similar features in the criteria for evaluating consolidation options.
Of course that assumes you have figured out what your organization actually needs when it comes to SD-WAN. In fact, this may be a good time to look at deploying a product at these remote locations that is capable of actually hosting additional virtual machines. There are, of course, pros and cons to doing this, but this should at least be considered. One of the longer term pros is that two or three years from now, when the “Next New Thing” comes along, it will probably no longer involve a physical device. You will be able to simply deploy a new VM on your already installed platforms – assuming, of course, you still have sufficient resources.
Once you’ve decided that you need to include some SD-WAN capabilities to your network, you should also look at the implications to your security practices. It would be a shame, for example, to repeat some of the mistakes that were made when WAN Optimization was a new thing. For WAN Optimization, the techniques used to optimize the communications (de-duplication, compression, header optimization, etc.) broke the ability for security services to be applied. There are similar challenges related to SD-WAN. And finally, there is also the whole cloud-centric approach that is fairly common to this space so that the end devices can be kept reasonably priced.
So, in summary, if you are looking into SD-WAN type technologies for your organization, then the following should be part of the evaluation criteria:
• Define the business benefits that you wish to achieve by deploying SD-WAN
• Ask your team:
1. Do any of our currently deployed technologies have functions that deliver some or all of the above benefits?
2. Are there other technologies that we should deploy at the same time?
3. Do we have time to look at the consolidation of technologies on a single appliance?
This is also a very good time to evaluate your deployment platform. If you can get all of the functionality from your current physical platform in a virtual form factor, maybe it’s time to look at virtual implementations that can reside on a shared x86_64 platform. Of course, that is a completely different – and complicated – discussion, but perhaps the timing is right and it just hasn’t been considered yet.