One candidate for the so-called “killer app” for SD-WAN is security, which is a popular but almost always vague claim for killer-app status for nearly everything. In the case of SD-WAN, there are security benefits to be had, but they are a part of a larger benefit I’ve noted in past blogs. SD-WAN could be a critical piece of the largely unrecognized function of virtualization-linked user/resource mapping.
Because everything on an IP network has to have an address, it follows that you can use the address of a source and destination to decide whether the two should be allowed to talk. There are two problems with this nice approach, though. First, you can’t be sure the address is authoritative, meaning that it really represents the originator of the packet. Second, in a virtual world, the address of either source or destination can change, so if you set up access rules based on one relationship, it might be invalid in the next moment when an instance of the application redeployed. SD-WAN could fix, or at least mitigate, both these points, but to see how we have to dig in a bit.
We see IP through the Internet, which we see as a vast “flat” address space where we can reach resources like websites and content. IP is actually a lot more complicated than that, and in some of my recent blogs I’ve explained a bit about the public/private address spaces and the fact that there’s a basic tension between the “what” something is and the “where” (in a network sense) it can be found. Virtualization complicates that fundamental tension by scaling things and moving them around.
In the world of resources, the what/where tension relates to things that, because they are resources, have to be addressable from the outside. Most real IP networks are a combination of resources and resource consumers. The consumer, user, side of the picture is very different from the resource side in that not only isn’t it necessary to address a user, it’s probably not desirable.
There you sit at your PC. You’re doing nothing online, and if no background processes are taking place, it’s not doing anything online either. You open a browser and you become a resource consumer, consuming the resource of a web server that provides you with your browser homepage, likely a search engine. This relationship demands two IP addresses, one for the web server and one for you.
Long ago, Internet thinkers realized that it wasn’t really necessary for these two IP addresses to work the same. The user device doesn’t have to be reached, only responded to. Servers know who you are because you contacted them. Thus, most Internet users have a private IP address that’s their location within their home network. A network address translation (NAT) process prepends the home’s IP address, assigned by your ISP, to a message you send. The web server responds to that address, which gets the response to your home gateway, which then unpacks the NATted address and gets it to you. This same process is often used within branch offices and even workgroups within offices, because it saves on scarce public IPv4 addresses. Without it, we’d have run out and gone to IPv6 long ago.
Modern container architectures, as I’ve noted in recent blogs, are also based on assigning private IP addresses within application subnetworks, then exposing the “public ports” in the corporate VPN space. Inside a virtualized container-hosted resource pool, the actual host can be anywhere. Again, as I’d noted, that means that you would expose selective interfaces, the ones intended for public access, but you’d have to map them to the proper host and load-balance them if there was scaling to be done. Some of the internal interfaces, representing scalable components, would also have to be load-balanced.
In theory, we could also look at a movable user model. A “real” user might access the company VPN via any number of on-ramps, each representing a facility or area in which the user might be operating, and also perhaps including a gateway to a mobile user. We might envision a translation here—private subnet address maps to “virtual user address”.
The common thread here, a thread SD-WAN might exploit, is the notion of having “local” or private addresses used as on-ramps for either applications or users. The thing they’re on-ramping to, of course, is another address space. Most SD-WAN technology builds a uniform VPN address space by doing some sort of overlay on a combination of connection technologies, including MPLS VPNs and the Internet. Since SD-WAN technology can sit in all business sites and many can also be deployed as a software agent in a cloud, it’s easy for SD-WAN to create an overlay VPN that can touch all users, all applications, all resources.
If you added in some logic, you could further enhance the mapping. Users and application components could have “logical names” and these names could then be used to attach instances of the components to a load-balancer. Logical names could also map real VPN addresses to instances hosted in private IP subnets or within a cloud provider. For end users, you could assign users logical names that would link them to a user- or role-specific subnet wherever they enter the network. This would require a sign-on process, of course.
If SD-WANs know enough to map at the logical level, they’d also know enough to do at least some rough validation of the addresses. If a component is to be allowed to register for a given “logical” address, it could be required to offer a token to validate its right. The same would be true, automatically, if you required user sign-ons. Further, you could validate the virtual or local address being associated with a given logical address to see if that on-ramp was allowed to represent a given user or resource. It’s not foolproof, but it’s a step forward.
Logical names don’t displace DNS servers and URLs. Those tools are associated with the public addressing of resources. The purpose of a logical name is to provide a linkage between a resource or user and that public-link portal point. We can assume that a component knows what it is, and so can use its logical name to get an association with a private/public mapping, probably through what I’ve been calling a “proxy load balancer”.
In some sense, application logical names could be related to the notion of “roles”, popular in public cloud spaces like Microsoft’s Azure. A role is a function that conveys access rights and that can be performed by multiple people. The proper use of roles can facilitate the development of forwarding/firewall rules to limit application access, protecting applications from maverick users and even from maverick components or malware. Roles would further improve security, and if you extended the notion of “roles” to software components, you could also make sure one software component didn’t try to link itself into a workflow it’s not entitled to participate in.
It should be clear that SD-WAN and SDN have a lot in common, and that SD-WAN vendors could incorporate some of the SDN features fairly easily. That may be a critical requirement, in fact, if those vendors want to establish some differentiation and also want to be able to address the carrier SDN market. Nokia/Nuage, who has arguably the best SDN offering out there, is also delivering SD-WAN solutions, and has probably the most carrier interest of all the players in the space.
Even clearer is the fact that while virtualization really depends on address mapping and remapping, we don’t pay nearly enough attention to the requirement. The first thing any IP-based system should do is define how it manages addresses within itself, and how it makes itself visible through IP addresses to the outside. SD-WAN could really codify this process, and then go on to provide a more complete implementation than we’ve had so far. If that happens, we don’t need to look further for killer apps for SD-WAN.