The IEEE Techblog has not covered this topic for a very long time, because there are no standards or accepted specifications for any type of SD-WAN or SASE interoperability. Those networks are all supplied by a single vendor, but that hasn’t stopped them from gaining market share, especially from legacy IP-MPLS VPNs. That’s even though functionality differs for each vendor’s SD-WAN or SASE offering and there is no interoperability, especially from one provider’s SD-WAN to another’s.
SD-WANs use Application-aware routing across the WAN, whereas classical SDN used a centralized controller to compute routes at the Network layer for the Control plane with “L2/L3 packet forwarding engines” in the Data Plane. The SDN Control and Data planes are separated with the “OpenFlow” API used to communicate between them.
NFV is not about routing but virtualizing network functions (“virtual appliances”) that would otherwise be implemented in hardware-firmware boxes.
Network virtualization (defined below) has played a key role in the popularity of SD-WAN and SASE, even though that network paradigm was not included in the original definition of SDN in which no overlay networks were permitted. (That was referred to as “SDN Washing” from 2011-2014, by SDN strongman Guru Parulker, now Executive Director of the Open Network Foundation.)
At many data networking industry conferences and events from 2011 to 2014, participants claimed that Software Defined Networks (SDNs) would usher in a whole new era for networking. One colleague of mine said it would be “a new epoch for networking.” Instead, there were various versions of SDNs, used primarily by hyper-scale cloud service providers (most notably Google and Microsoft) and a few large telcos (e.g. NTT, AT&T). But SDN never spread to enterprise or campus networks.
When SDN fizzled out, the industry’s focus shifted to Software Defined WANs (SD-WANs), which provides user control of a virtual network overlay via the Application layer. There are three components to a SD-WAN:
- SD-WAN edge is where the network endpoints reside. This can be a branch office, a remote data center, or cloud platform.
- SD-WAN Orchestrator is the virtualized manager for network, overseeing traffic and applying policy and protocol set by operators.
- SD-WAN Controller centralizes management, and enables operators to see the network through a single software interface, and set policy for the orchestrator to execute.
In addition, there are three main types of SD-WAN architecture: on-premises, cloud-enabled, and cloud-enabled with a backbone.
SD-WANs continue to roll out in many different shapes, forms and flavors, without any standards for any type of interoperability (e.g no UNI, NNI, Interface to legacy IP-MPLS VPNs, etc). Even the definition and certification by the MEF (Metro Ethernet Forum) has failed to catch on so there is no uniform functionality between one SD-WAN and another.
Because of its virtualized network architecture [1.], SD-WANs don’t require specific hardware for specialized network functions. Instead, the infrastructure is made of commercial off-the-shelf (COTS) equipment, also known as white-boxes. Therefore, all SD-WAN products are 100% software based.
Note 1. Network virtualization is the process of transforming network functions into software and disconnecting them from the hardware they traditionally run on. The software still consumes the hardware’s resources, but is a separate entity that can be changed, moved, and segmented while the hardware remains the same.
The virtualized and software-based version of the network is an overlay on top of the physical network infrastructure. The physical network’s devices like switches and routers still perform tasks like packet forwarding, while how to forward those packets is handled by the software running on the switches and routers.
Meanwhile a newer entry known as Secure Access Service Edge (SASE) has garnered a lot of media attention. This Gartner-coined product category, which combines elements of SD-WAN, cloud-based security, and edge computing, has gained significant traction in the two years since its inception.
SASE’s remote access functionality and low barrier to entry made it an attractive option for enterprises trying to cope with the rapid shift to remote work due to the pandemic. Within months of the first lockdown orders going into effect, nearly every SD-WAN and security vendor had announced a SASE security architecture, either through internal development, partnerships, or acquisitions.
SASE is the convergence of wide area networking, or WAN, and network security services like CASB (Cloud Assisted Security Broker), FWaaS (Firewall as a Service) and Zero Trust, into a single, cloud-delivered service model.
According to Gartner, “SASE capabilities are delivered as a service based upon the identity of the entity, real-time context, enterprise security/compliance policies and continuous assessment of risk/trust throughout the sessions. Identities of entities can be associated with people, groups of people (branch offices), devices, applications, services, IoT systems or edge computing locations.”
Gartner forecasts that, “by 2024, at least 40% of enterprises will have explicit strategies to adopt SASE, up from less than 1% at year-end 2018.”
A SASE architecture identifies users and devices, applies policy-based security, and delivers secure access to the appropriate application or data. This approach allows organizations to apply secure access no matter where their users, applications or devices are located.
According to Cisco’s latest CISO Survival Guide, almost all (98%) CISOs plan to spend money on secure access service edge (SASE), and 55% of them intend to prioritize 25% to 75% of future IT security budgets on it, according to
Cisco surveyed more than 100 CISOs and security leaders for this report. The biggest shift for CISOs this year is toward SASE, following the pandemic and related trend of working from anywhere in the world, said Dug Song, chief strategy officer at Cisco Secure.
“I think hybrid work is here to stay,” Song told SDxCentral in an interview. Most organizations have decided to maintain flexible work for employees even post-pandemic, which requires changes to their IT security programs.
Many industry experts say SASE services must be built on a cloud-native architecture (like 5G SA core network) and distributed across multiple edge locations.
While several vendors including Cisco and Fortinet have rejected the cloud native approach, arguing that networking and security appliances still have a role to play both at the branch and the edge, it’s a principle that’s reflected in Gartner’s own literature and wholeheartedly embraced by VMware, CATO and other SASE vendors.
Specifically, VMware offers a cloud-native SASE architecture that has combined multiple solutions in it such as SD-WAN Gateways, VMware Secure Access, ZTNA solution, SWG, CASB, AND VMware NSX Firewall. VMware delivers all these solutions through PoPs. It delivers the network and security services in an intrinsic or sequenced manner.
Cato CMO Yishay Yovel told SDxCentral, “The feeling I have is that a lot of the market is trying to talk about SASE now in a generic way, like everybody has everything, or everybody has the same capabilities, and it doesn’t matter exactly how they’re done.”
Yovel also said that just because a vendor claims to offer the full SASE software stack, doesn’t mean it’s been implemented in a way that’s scalable.
Many of the SASE functions — cloud-based firewalls in particular — are compute-intensive, they usually have to be run in cloud data centers and can’t run on the cloud provider’s more numerous content delivery network edge locations.
This dramatically limits the number of locations a SASE vendor can offer if relying on public cloud infrastructure. For example, Google Cloud claims services in 146 edge locations around the globe, but only operates 21 global data centers, which it refers to as regions.
Scalability and availability are another challenge, Yovel noted. In many cases, these virtual appliances aren’t multi-tenant and have to be assigned to a specific customer account, resulting in additional resources being required should the customer bump up against the limits of a single instance.
Yovel argues that unless a vendor’s SASE software stack is unified, customers may miss out on the ability to share context across multiple security or network functions. He explained that many functions, SD-WAN for example, are only aware of certain contexts like what application is being used, but this context could be used in conjunction with other contextual information like time, location, or identity to inform other parts of the SASE stack.
“We collect all the context elements. It doesn’t matter which part of these engines need them. Everything is built into a unified thing,” Yovel said.
The bottom line for today’s cybersecurity professionals is that both zero trust and SASE networking trends should be watched closely and integrated into forward-looking enterprise network architectural decisions.