What could be the possible reasons why even when the Internet had been cheaper since decade it is not adopted as an enterprise WAN?

Enterprises started using WAN (or connecting two or more of their branch) back in the 1980s, with T1/E1 point-to-point links. By end of 90s MPLS was there, which showed the world of how it can carry IP packets faster through the ISP “clouds”.

IPSec VPNs, got introduced in the mid-1990s and popularized in the late 1990s, made site-site connections over the Internet secure. But despite the price advantages of Internet connections, and despite the fact that the Internet in the last 20 years has revolutionized just about everything else that touches IT, but still fewer large enterprises used the public Internet for their site-site intranet connectivity until recently. Major reasons being:

1. QoS: On the Internet, there is no single service provider guaranteeing end-end performance all the time. You can’t get an end-end SLA over the public Internet. The business model of peering points precludes the ability to deliver any such SLA.
2. Reliability: If an internet link goes down, typically the meantime to recover strides more than a day or so. Partly because unless, it a last-mile issue, debugging peering related issues is overly complex and partly because the ISP for decades has treated the general Internet as a home/individual commodity. They never truly setup proper Internet support teams which can resolve the issue within defined ETAs. They already had a bigger cash cow to milk in the form of private WANs like MPLS.

So, in summary, Enterprise for the last 20 years got somewhat locked down into using only private WAN links. These private links based Enterprise WAN worked well when all the Enterprise Applications were in one place the Central Office or in its Private Data Center. The number of locations was limited and geographically fixed. Such Enterprise WAN was more or less a converged network connecting these fewer branch offices to the central location.

The modern-day Enterprise Networks need to do a lot more than just connect the branch offices to the data center and/or the central office. The private WAN links-based Enterprise Networks were never built for the era of the Cloud & Edge Computing. Everything and anything today have an IP connection. The Enterprise Network extends all the way from devices to employees to visitors to air conditioners to the refrigerator in the pantry, all needing an IP Connection to the Cloud.

Not, only IP connectivity, Enterprises’ adoption of Internet hosted SaaS applications are also increasing at a rapid rate. Nowadays, IT teams prefer to get Microsoft O365 subscription, rather than procuring individual Office Licenses and installing them on end-devices. And moreover, Enterprises are also steadily moving their content to SaaS for better consumption by their customers.

Today Enterprises need the following things from the WAN:

• Inexpensive and easy to procure bandwidth
• Reliable WAN
• Optimal Quality of Experience
• Security of Transported Data

The final answer lies in SD-WAN where the networking platforms can aggregate commercial Internet as well as private WANs like MPLS and provide a seamless fatter pipe as a WAN transport.

A lot of times, RAID analogy is given for SD-WAN, quoting that SD-WAN is doing the same thing to WANs, which RAID did to individual disk storages. Which is quite true. But one shouldn’t forget that RAID is not just an array of redundant disks, what made RAID successful is the intelligent software that is used to build a RAID array.

It’s about the Policies:

Whenever we talk about policies in the networking world, what exactly do we mean? A lot of times we come across jargon like PBR which is Policy Based Routing, QoS policies, Access Filter policies, etc. But what are they really and why they are needed? Can we today design a network edge platform without these policies? The answer is NO!

Policies are the most essential things in a networking platform today, as they are gateways via which an IT guys tell the device what he wants to do with the traffic. And in today’s complex world of communication, there can be hundreds of different use cases that the Enterprise world can come up with. Therefore, it is expected out of every modern-day networking platform that it should support highly flexible and intent-driven policy control.

For decades, we networking engineers are tuned to think that a packet in a forwarding plane traverses a series of tables lookups and finally egresses out of an interface. This thinking comes from the way hardware ASICs are designed so far in the networking world. Since the logics are predefined and fixed, hence there is no scope of adding non-trivial stateful functionality between the tables. But custom use cases were always present. So in order to handle logical processing, hardware-based network device vendors started leveraging fundamental constructs like network interfaces.

For some stateless simpler logic like tunnel header encap/decap, they made provisions for putting little microcode in the hardware itself. For stateful service, they created service interfaces (which are more or less like pseudo interfaces used to send the packet from a hardware ASIC layer to a microprocessor running software services).

All these, trickeries, were needed, because hardware once designed and fabricated, is a fixed entity. This rigidness of the packet path leads to the birth of complicated policies that we all see today. Unfortunately, some SD-WAN vendors, even today follow the same pattern of series of table lookups and actions as their principle packet traversal path.

In the ScaleAOn platform, the network admin is NOT expected to visit each branch’s web page and based on the availability of WAN types setting up the preferences for Internet breakout. Instead in ScaleAOn, we have an extremely powerful construct called Network Group. Network Group is the fundamental block that provides network segmentation in ScaleAOn architecture, more like VRFs. It’s basically a container of subnets that are allowed to talk to each other. However, unlike traditional, VRFs, Network-Groups are way more powerful in the sense that one can hookup policies, services, etc. at a Network-Group Level itself. Once a policy is set at a Network-Group level, all branch devices that are part of the same Network Group will get the policies.

ScaleAOn’s data plane is also is fully intent aware and functionally capable of interpreting the intent and doing the right thing. The data plane drives this power of consuming intents rather than fixed policies from the fact that the entire data plane has been architected using a flexible series of near axiomatic functional blocks. Each functional block derives its own role that should be played, from the overall intent to achieve the final goal.

Internet as a Secure Transport:

Even though we as individuals, day in day out we do online shopping and even online banking, but still, when it comes to using the Internet as an Enterprise WAN, we tend to get apprehensive about the security of our sensitive enterprise data that is getting transported. Enterprise IT teams are usually bothered about whether the Internet as a means of transport is secured or not? Which means that if there is a malicious user present on the Internet and if he somehow manages to sniff into the enterprise traffic which is getting transported via the Internet, will he be able to see or tamper with the contents of the traffic? Or in other words how safe is the Internet as a transport medium.

SSL VPNs were introduced back in the 90s. During a similar time frame, IPSec was also introduced. Both of these two technologies are now quite popular and both of them are powerful enough to make Internet secure, provided certain precautions are taken.

It is not the case that Enterprises today are unaware of security provided by IPSec protocol suite. They do acknowledge that IPSec, in particular, is a strong enough technology that can be used to provide a way secured transport over Internet WAN links. But still, they are hesitant to adopt the Internet as a WAN.

There are two main reasons for this:

One being the way IPSec Key management is traditionally done. Second, being the way IPSec (or for that matter the service of data security as a whole) is modeled in the classical networking world.

In large networks, IPSec key distribution is always a challenge. If you choose a static one-time key and copy it at every branch device, and later on if the key somehow gets into the hands of a malicious person then definitely it will cause immense troubles. Because of this, network devices usually employ dynamic key management via IKE protocols. Though as such there is no problem with IKE but configuring and maintaining it at a big Enterprise’s large number of branches has always been a big headache for the IT team.

Lavelle’s SD-WAN uses a little different way of managing these security crypto keys. The controller sends a random seed material via APIs towards the branch devices along with other parameters like key refresh timeouts. The data plane software takes this key material and then generates the actual crypto key, which is used for encrypting/decrypting user traffic, using a private algorithm. The generated crypto key is never stored back in the disk of the device. It always lives within the process address memory, and that too in an encrypted fashion, thereby limiting the chances of key stealth drastically. These generated keys are still refreshed quite frequently.

The next problem is the way IPSec is usually modeled in networking devices. As we discussed earlier, the traditional hardware-based devices have modeled, every other kind of service which doesn’t fit directly into their fixed table-based forwarding plane, as an interface oriented service, where forwarding tables divert the targeted traffic to these interfaces to get the services done.

Our SD-WAN platform doesn’t view data security and thereby IPSec as tunneling interfaces, but we rather our data plane treats them as a data transformation that needs to be applied before the data is sent over a path towards the peer branch. This gives us enormous flexibility and helps us scale in terms of providing secured data services to a large number of branches – like 1000+ even with moderate device hardware.

Also because of treating data security more like a transformation rather than a tunnel transport, helps us to provide seamless failover and even makes things like packet-by-packets load-balancing possible across a variety of hybrid WAN links.

With the Lavelle ScaleAOn SD-WAN platform, Internet-based WAN is not only secured and but also scalable.

Looking forward to better understand:

·  Challenges in Enterprise WAN space

·  Why the Internet as a WAN and SD-WAN as a whole is a necessity for the Enterprises

·  Why do we need an API driven approach for networking?

·  Why enterprise networking is more about Policies rather than protocols

·  How ScaleON uses the Internet as secure WAN transport

·  Some of the key points that helped our SD-WAN platform to scale

Watch this webinar to delve into how a 100% RESTful API architecture between nodes and network controllers, ScaleAOn SD-WAN can help enterprises leverage the richness of BGP without complexities of peering and protocol-based communication.