How do you bring the virtualization operations model to networking? That will be the job of Martin Casado, CTO of networking and security at VMware which this week launched NSX, the company's over-arching network virtualization package. Casado was one of the creators of OpenFlow, the protocol that spawned the software defined networking (SDN) movement. He was also the CTO of OpenFlow software provider Nicira, which VMware purchased in 2012, and which provides the basis for much of NSX. Casado met with Network World Senior Editor Ellen Messmer to talk about NSX networking and security implications.
Tell us about the security piece in NSX, such as this so-called NSX Service Composer.
NSX is a platform for virtual networking. If I create virtual machines, I can attack them in a virtual environment if they talk to anything on that network or the physical network. The attack surface is actually very large today. NSX introduces a layer of security and isolation. All communication in NSX has the capacity to be encrypted.
For a long time, VMware has talked about its virtualized firewalls in terms of vShield. Where is that going now?
VShield Edge is a component of NSX, a gateway for north-south firewalling. But NSX is more than that, it's the distributed firewalling.
In terms of the new vCloud Hybrid Service (vCHS) that VMware is offering through its four data centers, will vCHS support NSX, and if so, when? At a conference session about vCHS here at VMworld, the two technical marketing managers presenting the vCHS architecture indicated it's based on VMware's existing ESX and vShield Edge technology, not NSX which won't ship till closer to year end. They said they expected to start using NSX at some point in vCHS but weren't sure when that might be.
VCHS does not have NSX yet and when that will be, I don't know. The data centers concern the current VMware technology, and it will support older versions of the technology. NSX is the next software upgrade. It's important to maintain compatibility.
VMware is making a point these days of expressing support for multi-vendor hypervisors. Can you tell us about that and what might be the security limitations around it related to NSX?
Our goal is to change the network and we have to integrate with everything the network touches. Our charter is not to sell vSphere, it's to change the network. We need to be at each point-of presence in the network to do that. There are heterogeneous hypervisors deployed today, and physical workloads that aren't virtualized. Xen, KVM, Hyper-V -- we've got customers with OpenStack KVM deployments. NSX is an independent technology, a software layer that runs on servers at the edge, running on Xen, KVM, Hyper-V or control top of rack switches. Some of these platforms we don't totally control, like Linux. We have to go to the community upstream in a process for them to consider it. It may take time. In security services we can do what we want with ESX, we own the bits. With KVM, we have to go through the Linux community. There may be differences in time when some security services are available. There's a distributed firewall that runs in the hypervisor, available in ESX but not KVM. It will take upstream support. But eventually, all will be available on all platforms.
As you are likely aware, the tech press covering the NSX announcement this week, based on analyst input about it, widely reported NSX network virtualization as VMware bumping up against Cisco in a battle over software-defined networks. Can you comment on that?
The deepest relationship VMware has with any hardware vendor is with Cisco. You have VCE. They're a very strong partner. We need physical infrastructure as we send packets around. We love Cisco! NSX is totally compatible with Cisco products. That said, partnerships all evolve at their own pace and have their complexity.
HP made news this week as supporting NSX. What are they doing?
HP is doing a technical integration on top of Rack Switch to include it in the NSX environment. We will never do physical switches...
Back to NSX Service Composer, we heard this week that there's an ambitious plan to have the various vendor software products tied to NSX, such as antimalware or intrusion-prevention, be able to share security information to somehow automate a response among products. That would be rather unusual. How would that actually work?
NSX Service Composer is a high-level framework for policy declarations. You can have a complex security policy, but it's manageable. You can evolve it. But it's not a vertically locked-down layer. Because we're in the hypervisor, we have a tremendously granular view on the host. We know a lot. If one of our partners detects there's a virus, it can tell NSX and NSX can put this into quarantine. We can facilitate the communications.
NSX also has this distributed firewall. How is this different from vShield?
With vShield Edge, if you send traffic out onto the Internet, you have north-south traffic. But if one VM talks to another VM in a data center, you don't want to send that traffic through a choke point. The NSX distributed firewall is a full stateful firewall in the hypervisor. Before, it was just access control lists.
Some of VMware's security APIs for security vendors have not proven hugely successful in the past and adoption of virtualized security products in general has not been widespread in the overall marketplace so far. You've only been with VMware one year since joining them after the Nicira acquisition, but why will the future of virtualized security be better?
We have real customer traction and we've focused on operations. New technologies go through maturation cycles, and we're pre-chasm -- we haven't gotten to the majority yet.
Ellen Messmer is senior editor at Network World, an IDG publication and website, where she covers news and technology trends related to information security. Twitter: MessmerE. E-mail: email@example.com
Read more about data center in Network World's Data Center section.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.