SD-WAN: I Can See Clearly Now

It may sound like an obvious thing to say, but one of the key requirements for a successful Software Defined WAN (SD-WAN) solution is the ability to make intelligent decisions about where to send each packet. The problem is more and more applications are turning to encryption to protect their payloads, and that means every packet starts looking the same because the content isn’t available for analysis. Riverbed believes that their years of experience pulling apart applications at the packet level gives them a leg up on the SD WAN competition.

SSL Is The New Transport

Plain TCP makes application analysis so much easier; we can look inside the packets and, assuming we know the structure of the data for that particular protocol, decode the content and figure out what’s going on. It’s no coincidence that Riverbed is the corporate sponsor for Wireshark as there’s a natural symbiosis between the packet inspection needs of a WAN acceleration solution and the packet analysis capabilities of Wireshark. This is all great until encryption comes into the picture.

Encryption is the becoming a regular means of application communication, and will undoubtedly only become more so over time. Encryption is the natural enemy of packet inspection. Without accurate application layer information to inform decisions, an SD WAN device may be left to infer information about the encrypted data stream by monitoring what little data are visible (such as TCP port numbers) and other behaviors like DNS queries to make a best guess as to the application’s protocol and intent. This is suboptimal to say the least, and if as Riverbed suggests, SSL is indeed the “new transport” (replacing TCP as the default communication channel), the problem is only going to get worse.

Man In The Middle

Riverbed have been facing the encryption challenge for years now with their WAN acceleration products. Put simply, the only way to see inside an SSL stream is to be one of the endpoints in the conversation, so the WAN device has to terminate the outgoing SSL session by pretending to be the remote server, then create a second SSL session on the back side to the real destination. In between those two SSL sessions, data is in the clear and can be analyzed in detail. To do this seamlessly–without certificate errors–the WAN device has to have the private keys for a certificate(s) that clients will trust. However, many companies are reticent to have their valuable private keys sitting on to devices in branches that may not have the same level of physical security as the data center environment would offer. Riverbed’s solution is simple but clever and relies on the fact that the SSL negotiations perform two main tasks:

1. Confirm that the site you connected to is who you thought it was;
2. Negotiate an encryption key in such a way that it can’t be seen in transit.

Riverbed’s SteelHead product has the ability to intercept the outbound SSL session and pass on the SSL key negotiation process to a centralized server (one in your data center, perhaps with a Hardware Security Module for additional key protection). The SSL certificate exchange and key determination happen between the end client and the centralized server, and no keys need to be stored on the SteelHead. At the end of the negotiation when the encryption keys have been agreed, the centralized server securely communicates the session encryption key to the SteelHead, and that device can now encrypt and decrypt traffic with the end client as if it were involved all along. And because the SteelHead has the encryption key, it can perform full analysis of all the data being sent by the client and server.

Applying Intelligence To SD WAN

So if SSL is indeed replacing TCP, an effective SD-WAN product has to be able to act as a “man in the middle” for SSL encrypted flows. Additionally, the device has to have a rich library of application and protocol decoders in order to extract the best information from the data flowing through the device. Decisions can then be made regarding QoS, the path it is sent out on, and whether to redirect it to a cloud-based SteelHead VM colocated with, say, office365.com servers in an Akamai data center. Why do we care? Because this level of information gives us two key things:

1. The ability to implement policies on the WAN, ensuring that performance is improved and business critical applications always get the access they need to the network. Riverbed have previously described trying to make the WAN invisible to the business and the applications.
2. Visibility. Through the use of centralized management, detailed data about the nature of branch office traffic can be reported even if it leaves through a local Internet link and never hits the data center. As this visibility expands to the cloud, businesses will be able to have full visibility of the traffic ingressing and egressing all their sites.

This begs the question, if you can’t see inside encrypted flows, how intelligent can your SD WAN solution actually be?

But Wait, There’s More

I want to add that today at least, Riverbed appears to offer a very competent SD-WAN solution based primarily on their ability to see inside the data flows and decode protocols. From this base, the logical next steps are to strengthen the cloud features and add edge router capabilities to the appliances so that they can manage multiple WAN links directly. Riverbed is making strong steps in the latter direction with Project Tiger and the new SteelOS operating system, and the acquisition of Ocedo seems very promising with regard to the former. If Riverbed can pull this all together successfully and offer a solution for all sizes of site as well as the cloud, their market-leading flow insights mean they will likely be a formidable player in the SD-WAN market.

---