On May 14th 2020, Marcel Gamma, tech industry journalist, and editor-in-chief at inside-it.ch and inside-channels.ch, published an article discussing several glaring security vulnerabilities in Silver Peak’s SD-WAN products on inside-it.ch. The original article was written in German; Marcel was kind enough to translate it into English and get permission from his publisher to have the English version published on ipSpace.net.

Security researchers make serious accusations against SD-Wan manufacturer Silver Peak. The latter disagrees. Swiss experts are analyzing the case.

By Marcel Gamma,

Silver Peak is accused of laxity in dealing with security issues and in dealing with security researchers who act within the framework of Responsible Disclosure.

After describing Cisco SD-WAN fundamentals and its network abstraction mechanisms, David Penaloza explained the components of Cisco SD-WAN solution and its architecture, including in which plane each element operates and its assigned role in the overlay network.

I don’t know what’s wrong with me, but I rarely get emails along the lines of “I deployed SD-WAN and it was the best thing we did in the last decade” (trust me, I would publish those if they’d come from a semi-trusted source).

What I usually get are sad experiences from people being exposed to vendor brainwashing or deployments that failed to meet expectations (but according to Systems Engineering Director working for an aggressive SD-WAN vendor that’s just because they didn’t do their research, and thus did everything wrong).

Here’s another story coming from Adrian Giacometti.

After setting the stage clarifying the current Cisco SD-WAN deployment scenarios, David Penaloza focused on definitions and fundamentals that must be considered before dealing with solutions that hide and abstract complexity like overlays, routing, and network virtualization from the network administrator.

David Penaloza decided to demystify Cisco’s SD-WAN, provide real world experience beyond marketing hype, and clear confusing and foggy messages around what can or cannot be done with Cisco SD-WAN.

He started the first part of his Cisco SD-WAN Foundations and Design Aspects webinar with a quick look beneath the surface of shiny marketing and corporate slidess.

A reader of my blog was “blessed” with hands-on experience with SD-WAN offered by large service providers. Based on that experience he sent me his views on whether that makes sense. Enjoy ;)

We all have less-than-stellar opinions on service providers and their offerings. It is well known that those services are expensive and usually lacking quality, experience, or simply, knowledge. This applies to regular MPLS/BGP techniques as to - currently, the new challenge - SD-WAN.

In January 2020 Doug Heckaman documented his experience with VeloCloud SD-WAN. He tried to be positive, but for whatever reason this particular bit caught my interest:

Edge Gateways have a limited number of tunnels they can support […]

WTF? Wasn’t x86-based software packet forwarding supposed to bring infinite resources and nirvana? How badly written must your solution be to have a limited number of IPsec tunnels on a decent x86 CPU?

It’s amazing how quickly you get “must have feature Y or it should not be called X” comments coming from vendor engineers the moment you mention something vaguely-defined like SD-WAN.

Here are just two of the claims I got as a response to “BGP with IP-SLA is SD-WAN” trolling I started on LinkedIn based on this blog post:

Key missing features [of your solution]:

• real time circuit failover (100ms is not real-time)
• traffic steering (again, 100ms is not real-time)

Let’s get the facts straight: it seems Cisco IOS evaluates route-map statements using track objects in periodic BGP table scan process, so the failover time is on order of 30 seconds plus however long it takes IP SLA to detect the decreased link quality.

In the Three Paths of Enterprise IT part of Business Aspects of Networking webinar I covered the traditional networking vendor landscape. Let’s try to do the same for SD-WAN.

It’s clear that we have two types of SD-WAN vendors:

This is a guest blog post by Philippe Jounin, Senior Network Architect at Orange Business Services.

You could use track objects in Cisco IOS to track route reachability or metric, the status of an interface, or IP SLA compliance for a long time. Initially you could use them to implement reliable static routing (or even shut down a BGP session) or trigger EEM scripts. With a bit more work (and a few more EEM scripts) you could use object tracking to create time-dependent static routes.

Cisco IOS 15 has introduced Enhanced Object Tracking that allows first-hop router protocols like VRRP or HSRP to use tracking state to modify their behavior.

Christoph Jaggi sent me this observation during one of our SD-WAN discussions:

The centralized controller is another shortcoming of SD-WAN that hasn’t been really addressed yet. In a global WAN it can and does happen that a region might be cut off due to a cut cable or an attack. Without connection to the central SD-WAN controller the part that is cut off cannot even communicate within itself as there is no control plane…

A controller (or management/provisioning) system is obviously the central point of failure in any network, but we have to go beyond that and ask a simple question: “What happens when the controller cluster fails and/or when nodes lose connectivity to the controller?”

SD-WAN is the best thing that could have happened to networking according to some industry “thought leaders” and $vendor marketers… but it seems there might be a tiny little gap between their rosy picture and reality.

This is what I got from someone blessed with hands-on SD-WAN experience:

This blog post was initially sent to subscribers of my SDN and Network Automation mailing list. Subscribe here.

I made a statement along these lines in an SD-WAN blog post and related email sent to our SDN and Network Automation mailing list:

The architecture of most SD-WAN products is thus much cleaner and easier to configure than traditional hybrid networks. However, do keep in mind that most of them use proprietary protocols, resulting in a perfect lock-in.

While reading that one of my readers sent me a nice email with an interesting question:

A while ago we published a guest blog post by Christoph Jaggi explaining the high-level security challenges of most SD-WAN solutions… but what about the low-level details?

Sergey Gordeychik dived deep into implementation details of SD-WAN security in his 35C3 talk (slides, video).

TL&DW: some of the SD-WAN boxes are as secure as $19.99 Chinese webcam you bought on eBay.

Here’s some feedback I got from a subscriber who got pulled into an SD-WAN project:

I realized (thanks to you) that it’s really important to understand the basics of how things work. It helped me for example at my work when my boss came with the idea “we’ll start selling SD-WAN and this is the customer wish list”. Looked like business-as-usual until I realized I’ve never seen so big a difference between reality, customer wishes and what was promised to customer by sales guys I never met. And the networking engineers are supposed to save the day afterwards…

How did your first SD-WAN deployment go? Please write a comment!