The Virtual Data Center

My favorite quote from RSA: “TheVirtualDC? Your blog is about virtualization and data centers, not security. Why do you even want to come to RSA?”*

Ahhh, finally back at the home office after two weeks of conferences: VMware Partner Expo in Orlando and RSA in San Francisco (with a pinch of SAP Virtualization Week thrown in the middle for flavor). It was a tiring trip but an excellent one for getting out in the field and talking to folks about virtualization and, as much as they would let me, security. I’ll have write-ups of each of the shows over the next week beginning with RSA today.

So RSA, we’ve known each other for years and sometimes you impress and sometimes you disappoint. I’d have to lean towards the latter this year; you really didn’t feel new and exciting. I was hoping that there would be a much larger virtualizaiton (and yes, cloud) security push this year than I saw, but the majority of what I witnessed in public (admittedly this was limited to the expo floor and partner-esque conversations due to a great list of analysts meetings that kept me from the general sessions) was the same ol’ same ol’: AV, IAM, UTM, network security, application security, FOBs on your iPhone, etc.

Now don’t get me wrong: obviously these are extremely important tools and technologies, but I guess I was expecting RSA to hold form and be more than the standard security show. If this year is any judge RSA will be returning to it’s pure security roots moving forward. Much like a storage show focuses solely on drives, data, and transport, RSA may be headed back to the days when us security geeks went to dig way down into the security internals. If that’s true, we had a few great years where RSA opened its arms to everyone. There was a time when it really felt that security was leading rather than following, and I just didn’t get that feeling with the show itself this year. The show felt like a necessary evil.

In contrast, the 1:1 meetings I had throughout the week were exactly as I’d hoped: Where’s security going? How can we use these security tools to create integrated solutions for the data center? What are the threats with cloud computing? How come virtual platform providers still haven’t moved beyond securing VMs and their flat virtual networks? Why is it still so easy to create VM trojans? Those were the amazing conversations I had outside RSA; talking with people who are passionate about security. But those interesting and productive conversations felt like we were whispering behind the gym in high school, as if we’d sneaked out of Physics 101 class to build our own rocket. And that alone, that feeling of making progress while the rest of the world remained stagnant, was worth the trip alone.

I know there were some great sessions on virtual and cloud security with Hoff, McKeay, and others that I didn’t witness first hand. I look forward to hearing/reading about those once RSA is officially done. And I can’t write a post about RSA without mentioning the excellent time I had at the RSA Security Bloggers Meetup 2009, another example of moving miles ahead outside of the organized show in just a few hours. Sure the drinks were flowing, but I still took copious mental notes and left excited with a smile on my face.

Anyway I’m already looking forward to next year, hoping that 365 days from today I’ll be writing about how far we’ve come in the past year on topics like virtual platform security. Until then I’ll just need to make sure I stay busy for the cause.

*In case you’re curious, that direct quote was made by someone working the show behind the scenes, someone extremely familiar with RSA. Awesome.

I’ve been heads-down for the past few weeks in product land so I haven’t had much time to poke my head up into the clouds. I’m now standing up straight again, stretching, and getting back to thinking about the larger macro issues that cloud presents. Today I’m going to talk about one very specific issue: overlapping IP addresses and spaces by users of a common cloud.

This topic was spawned by a comment to an earlier post on the cloud. Here’s the comment:

In the Virtual Data center deployments/cloud, do you see a chance of IP address clash with the subscribers? Subscribers would want to have freedom to select the IP addresses. In such cases, how the network setup will be?

Ravi, the commenter, brings up a great point. The cloud is shared computing space so that’s got to include the network, and unlike computing resources and other parts of the network, such as MAC addresses, which are always unique until exhausted, IP addresses are such a small, finite pool of unique identifiers they have to overlapp at some point. We’ve seen this for years with companies that acquire other companies and attempt to combine and merge two different networks that share overlapping private IP addresses. And on a much smaller scale with home router users that end up using default IP addresses, typically either 192.168.0/24 or 192.168.1/24; basically any of them if they don’t change the default Linksys/Netgear/D-Link setting.

Like home users, the concern with share IP addresses in the cloud isn’t with public IP addresses; those are governed and for the most part rigid. The problem is inside the cloud, where IPv4 cloud providers are limited to one of three banks of private, non-routable IP addresses: 10/8, 172.16/12, and 192.168/16. On their own, this range encompasses almost 18 million IPv4 addresses, which will be plenty for most cloud providers. However there are two issues for pause, even with a pool of 18 million IPs to choose from:

1. Extremely large cloud providers, such as AWS. It’s not unrealistic to imagine that Amazon could support at some point more than 18 million unique workloads at once (in this case workloads meaning applications tethered to a unique IP address). Even as they were to get close to that number, management of re-usable IP addresses would be a challenge. They would have to know by the second which workload was using which IP address, when that workload relenqueshes that IP address, re-assigning the IP, and then the technical challenge of ARP management with such high-volume IP turnover.
2. Cloud providers that accept pre-configured workloads, say from internal private clouds. Company A may have a series of applications, bundled together in something like VMware’s vApp, that all use IP addresses in 192.168.22/24. Company B may have an vApp bundle with an overlapping range, such as 192.168.20/22. Given a large enough customer pool using vApp in an external cloud provider, there will be customers that use overlapping IP addresses on the same cloud network, and these customer IP ranges most likely won’t fall on easily defined subnet borders.

So what’s the solution (ruling out IPv6 since Ravi is probably asking about IPv4)? Thankfully there are a number of tools available that will virtualize networks above layer 2, virtualizing the IP space in the same way that VLANs virtualize frames. To address this issue, a cloud provider can use some network management device that will virtualize layer 3 before or at the same time customer traffic in the cloud is translated (via NAT) from a public IP address to a private IP address. As a request for a service in the cloud comes into the cloud edge, the network or application management tool will recognize the request for a specific customer and move that request over to the segmented layer 3 network isolated for that specific customer. Very much in the same way we tag frames and ports with VLAN data, a segmented layer 3 network can be created with “tagged” IP addresses that are destined for different parts of the network.

Ravi hit a core requirement for the cloud: in a true multi-tenant environment, overlapping IP addresses must be supported and cloud customers must be able to select any IP address they’d like, either during service creation or as part of a pre-configured virtual application bundle. Customers need to be able to say “This application must use this IP address” and not have to worry about the cloud provider returning a “Sorry, IP address already in use” error. So to answer his question, yes, I absolutely see a need for overlapping IP addresses inside the cloud, but as long as the cloud is built to support that architecture, overlapping IP addresses shouldn’t be a problem for cloud customers.