Riverbed’s entry –or perhaps “expansion”– into the SD WAN market is interesting to me primarily because the approach being taken is a little different from the other solutions I have seen so far.

The Rest

The solutions I’ve seen from vendors like Viptela, Silver Peak, Cisco, CloudGenix and VeloCloud mainly focus on providing reliable and optimized transport from spoke site to hub site, and in some cases also from spoke to spoke, and in fewer still, spoke to Internet. The underlying approach is to monitor various statistics for each of the available WAN links, and intelligently route data flows over the link that will best meet the application’s needs. Some solutions add error correction and/or packet duplication techniques to overcome packet corruption and loss as well. Let’s call this Link Selection, noting that both links are used so it’s not a “one or the other” kind of thing.

Riverbed SD WAN

Riverbed has come at this problem from the angle they know best, WAN optimization. The presentation Riverbed gave at Networking Field Day 10 was not about how to choose which link to use, but more about how to effectively manage a hybrid WAN (say, MPLS for corporate access in addition to direct local Internet access which may or may not also have VPN back to the corporate hub location), and determine how best to route the data flows to optimize performance. Add in Riverbed’s long expertise in WAN optimization through various compression and caching techniques, and you have a compelling story for how Riverbed can benefit your business. When Riverbed talks about “SD WAN Path Selection”, it seems to be a discussion about whether to send traffic directly to the Internet or pass it through the hub site; subtly different from Link Selection.

In fairness, while Riverbed seems have put aside the Link Selection functionality that prevails in other solutions, the Path Selection process is similarly absent from other SD WAN solutions. With the number of cloud-based applications now being used by the typical enterprise, Riverbed makes an interesting case for why their product may be the one you want.

Optimizing SaaS in the Cloud

If an Enterprise already has Riverbed SteelHead WAN optimization in place, the optimization between corporate sites is a given. However, as SaaS gets progressively more common (look at the huge growth of Office365.com in the last few years for example), some of those benefits start being lost. Once upon a time, a user’s connection to the corporate Exchange or a SharePoint servers ran over optimized WAN links to the hub site, and bandwidth was minimized within reason. When SaaS comes into the picture, that traffic now has to traverse the Internet, which leads to the question of whether that traffic should go through the hub site or instead go directly to the Internet from the site’s local link? If the former, WAN bandwidth is consumed, but the hub site’s Internet link will take a heavy aggregated load. It the latter, the load is distribute among the branch sites, but that direct Internet path benefits from no WAN optimization.

SteelHead SaaS aims to solve that problem by way of a partnership with Akamai, arguably the largest global CDN. With an appropriate license in place ($1.99/user/month), when a session is initiated to an Akamai-hosted service (including box.com and office365.com), Akamai can dynamically spin up a VM-based SteelHead instance, and associate to the SteelHead at the branch site. Now, each branch site has a direct, WAN-optimized path to the cloud. Impressive stuff, and the benefits for file upload/download demonstrations presented at NFD10 were impressive to say the least.

TCP Proxy

What’s more, Riverbed watches the DNS and traffic exchanges taking place, and attempts to identify when an initial query to a site in one location ends up redirecting to a download location in another location, and dynamically shift its connections and optimization (if necessary) over another path. To do this, Riverbed acts as TCP Proxy for all the sessions passing through it, inspecting the content and analyzing the application transactions. The argument is that the connection from client to Riverbed remains untouched when a path is re-established, but the path from Riverbed to the end can be torn down and rebuilt at will without the client ever knowing about it. There are definitely limits to this solution, but conceptually it’s great.

SSL Proxy

Riverbed describe SSL as the new transport, replacing plain old TCP/IP for most applications. Looking around, they’re probably right, and these encrypted streams certainly create a headache for a company whose products are trying to look into the application traffic in order to best optimize and cache the data passing through. In order to remain effective, the Riverbed device has to be able to decrypt a data flow, look at the content, compress or use local caching to fulfill the request, then for ongoing traffic, re-encrypt it before sending it on its way.

SSL Proxies are not exactly new; the concept is that the proxy device pretends to be the desired SSL destination (even to the point of issuing a wildcard certificate so that all SSL session can terminate on the proxy device). In order for that to work, the proxy device has to have certificates issued by the Enterprise, and the issuing Certificate Authority has to be trusted by all users in the organization in order for the fake certificate to be accepted by browsers and other clients.

Security Risks

Think about it for a moment though; if we were to put a wildcard SSL certificate in an SSL Proxy in a branch office, we have to also supply the private key that makes it work. This is a potentially huge risk; equipment at branch sites are frequently physically insecure, and should the private key be compromised, a malicious actor could insert themselves as a ‘man in the middle’ anywhere in the Enterprise, for any site they chose.

Riverbed have approached this from two directions. The first is that some SteelHead devices have the ability to support a Hardware Security Module, a device offering secure storage and access to valuable private keys. Great, but thats an expensive thing to have to do across the Enterprise. Centralizing SSL decryption at the HQ where the HSM is located means having encrypted sessions from branch to HQ (where the SSL Proxy resides), and the result is suboptimal compression and a lack of caching capability within the branch site. What is needed is the ability to terminate the SSL session locally within the branch, but somehow keep the private keys secure in the hub site data center. So that’s exactly the solution Riverbed has developed. While Riverbed was not entirely forthcoming about the ‘magic’ that makes this solution work, here’s the rough overview of this idea.

Establishing an SSL Session

At a high level, SSL sessions are set up in two phases:

1. Use asymmetric encryption to establish a secure channel over which to communicate. This is achieved by the exchange of public certificates. This might be sufficient and is certainly secure, but asymmetric encryption is computationally expensive, so isn’t a desirable solution for the encryption of the session data.
2. Within the asymmetrically encrypted secure channel, agree a random encryption key to use for the rest of the session’s encryption. The same key is shared by both ends of the connection, which allows them to use symmetric encryption going forward. Symmetric encryption is far more CPU efficient than asymmetric encryption, so this is a preferable solution.

If you’ve ever used PGP to encrypt emails and files, the process is very similar. The public and private PGP keys are analogous to the public and private SSL certificates. In PGP the keys are really used to communicate (and encrypt/decrypt) a long symmetric key that is used to encrypt the rest of the communication.

Riverbed’s logic is thus:

• It’s important to keep the private keys in the secure data center.
• Once the symmetric key has been determined, it’s used for the rest of the SSL session, and the private key isn’t needed again.
• Thus, if the SteelHead at the secure data center can be used to perform the initial certificate exchange process and symmetric key determination, then after that, the session-specific symmetric key can be securely sent to the branch SteelHead, and that local device can then decrypt traffic as close to source as possible and make the most of optimization opportunities.

Again, some pretty clever logic, and while the precise supporting packet exchanges by were not disclosed, Riverbed assures us that this works.

Is This SD WAN?

Well, here again is my own reference definition, right or wrong:

“SD WAN is a solution that uses real time WAN link performance monitoring and data packet inspection to autonomously manage the distribution of network traffic across multiple, likely heterogenous, WAN links with the aim of improving and optimizing WAN performance in alignment with the business requirements.” – John Herbert

Well, Riverbed don’t really talk much about the performance monitoring side of things in the context of directing WAN flows, but the solution is definitely aimed at improving and optimizing WAN performance. Management and monitoring is all through the SteelHead Central platform, so the platform arguably has a centralized/separated control plane of sorts. I confess, when I think about Software Defined WAN, this isn’t quite what comes to mind, but actually it’s not so different for the other solutions out there, even though the approach is slightly different. I don’t see elements in here that are focused on mitigating the impact of packet loss or jitter on WAN links, but the optimization techniques are without question thorough.

Open Standards

Looking back, we didn’t really ask about open standards because I think it was pretty clear to us all that this is a proprietary solution developed over many years. The up side to this is that Riverbed have been doing this so long, it’s should be a solid platform, and while some features are new, much of the underlying technology is very well established. So, proprietary, but probably less risky than some others out there.

Intelligent Software Defined Hybrid Smart WAN Cloud Solution Idea Thing

I get the feeling that there’s probably a very clever solution available if one were to use Riverbed’s solution for intelligent path selection with another SD WAN solution to optimize traffic to and from the corporate hub site.

In other words, let a link-optimization SD WAN solution handle the corporate connection and let Riverbed handle the path and content optimization in the first place. Winning?

This post is running long, and I’ve still yet to mention Project Tiger! I’m going to come back to that in a post coming shortly, and in that same post I’ll also link to the Networking Field Day videos from Riverbed so that you can catch up on the full, gory detail from the horses’ mouths, as it were.

 

 

Disclosures
I attended presentations by Riverbed as an invited delegate at Networking Field Day 10. Vendors pay money to present to delegates, and in turn that money funds my transport, accommodation and comestibles while I am there. That said, I don’t get paid anything to be there, and I’m under no obligation to write so much as a sausage about any of the presenters, let alone write anything nice about them. So if I do so, you can rest assured that I’m saying what I want to say, and I’m writing it because I want to, not because I have to.

You can read more here if you would like.