I'm a huge fan of Linode and have no intention of going elsewhere. But I would like to encourage Linode to consider some more advanced features when it comes to private networking of Linodes. RackSpace just released a new feature to their customers called Cloud Networks (http://www.rackspace.com/blog/cloud-net ... pen-cloud/). Basically, you can create truly secure private networks between your nodes. Furthermore, you can use the feature to build multi-tier networks.

I'll leave it to the reader to draw conclusions of where all one could take this technology, but I will suggest that it would simplify building PCI compliant n-tier application networks on Linodes - allowing for true private/DMZ/public network configurations. And the other possibilities are endless.

Also, I would like to point out that RackSpace themselves exposed their next step in development of this technology: "allowing you to create advanced, networking configurations spanning multiple regions." If Linode could implement custom private networks in a way that spanned multiple data centers before RackSpace implemented it, Linode would be one step ahead!

Anyhow, I'd love to hear comments from both Linode developers and users.

Thanks for reading,
Steve

Isn't this what openvpn was created for?

_________________
Rgds
Stephen
(Linux user since kernel version 0.11)

Look at what Rackspace charges versus what Linode charges.

Imagine what Rackspace's R&D budget is versus what Linode's R&D buget is.

Think about how many engineers each company has to throw at such a project.

Personally, I don't want to Linode to start charging Rackspace prices, nor do I want Linode to start providing crappy Rackspace customer service.

Why is it some people just can't leave a successful business model alone - not every provider needs to be a swiss-army knife.

_________________
Either provide enough details for people to help, or sit back and listen to the crickets chirp.
Security thru obscurity is a myth - and really really annoying.

I've contemplated using openvpn on the private network, but a solution like that probably wouldn't survive a serious PCI compliance audit. Plus, running a vpn chews up quite a bit of processor cycles.



Again, as I said, I'm sticking with Linode. However I don't buy the fact that it takes a huge R&D budget to accomplish what Rackspace is doing with private networks. I think it takes creative people coming up with a creative solution to a problem. It simply requires thinking outside the box. And it would hardly require turning Linode a swiss army knife.

I am curious however, if anyone else sees the value in something like this... or if its just me. I know I've regretfully had several clients that I had to steer other places because we simply couldn't implement what they wanted to do on Linodes, and the primary reason was because of how the private network was implemented.

It looks like all RackSpace did was build a web interface for Open vSwitch, which is built into XenServer anyhow. Not all that much R&D required...

That said, there seems to be no real difference between doing that and using OpenVPN, except that RackSpace's solution is totally unsecured, in that it really just gives you software VLANs and still has your data flying around over their internal network in the clear. With OpenVPN, you get the same functionality, but your data is encrypted while it flies around.

If anything, the OpenVPN solution is both more flexible and more secure.

I'd argue the opposite; with openvpn you control the endpoints and secure the data transmission, rather than relying on an outside config that's external to your machine. OpenVPN is the _more_ secure solution.

_________________
Rgds

Stephen

(Linux user since kernel version 0.11)

Plus OpenVPN can be used cross-vendor; you could have servers hosted with multiple suppliers and secure a network between them.

_________________
Rgds

Stephen

(Linux user since kernel version 0.11)

I definitely understand your point of the security of OpenVPN in this situation... its perfectly logical... but sometimes the PCI standards are illogical and fail to keep up with technology like this. I've been through audits before that would fail on this, simply because it doesn't fit the "standard".

Another of my initial concerns with OpenVPN on a Linode is the CPU utilization (based on previous experiences with OpenVPN on multiple Xen guests). I don't know if things have gotten any better in this regard over the past couple years... possibly some testing is in order.

And then there's the simplicity of someday being able to click "add a secure private network" in the admin to set up secure networks of several Linodes. OpenVPN config on the other hand... not so simple. The primary reason I stopped hosting my own Xen servers and switched to Linode is that they make it so much simpler. I spend less of my time managing the Xen nodes and more of my time on the servers themselves building out the business solutions. Simple is good. Linode is good.

I've never had a problem with openvpn using a lot of cpu on Linode, I've been using it on and off for years.
As for rackspace, they still use ftp for their cloud sites, I don't think security is their highest concern

_________________
Paid support
How to ask for help
1. Give details of your problem
2. Post any errors
3. Post relevant logs.
4. Don't hide details i.e. your domain, it just makes things harder
5. Be polite or you'll be eaten by a grue

OpenVPN does have some "click to enable" style options, like OpenVPN Access Server (a commercial product). It's intended for more of a star topology, though, if memory serves.

OpenVPN CPU usage is really not a concern; a single core in a Linode should be able to saturate a gigabit connection, but your linode has four cores, and can't send at one gigabit (50 Mbps upstream cap by default, subject to increase if you request and need it).

I'd be surprised if the PCI standards don't include any mention of VPN, since VPNs are as old as the hills. Bizarre unencrypted and insecure software-VLAN stuff like what Rackspace is doing would be far less likely to be covered by the PCI standards. Sending all of your data in the clear over an untrusted network really doesn't sound like a great idea when you're dealing with credit card info...

PCI standards (I work in security in a megabank; there's a good chance you have one of our cards) typically have high-level security requirements and then, as the auditee, it's up to you to demonstrate how you meet those requirements. Using "standard technology" makes it easy to demonstrate. Using 'something else' makes it an education campaign; you need to educate the auditor.

Dealing with auditors is an art. A properly managed OpenVPN solution will pass PCI "[e]ncrypt transmission of cardholder data across open, public networks" requirements; an externally managed VPN (such as Rackspace's) would be harder to prove since that will require your auditor talking to Rackspace to prove their setup is encrypted and can not allow untrusted endpoints to join the VPN and sniff the traffic. Alternatively ensuring that your endpoints use SSL encrypted channels (eg SSH) for all communication would also meet the requirements; no VPN needed.

_________________
Rgds

Stephen

(Linux user since kernel version 0.11)

Proving that Rackspace encrypts is difficult since they never claim it does, and the software they're claiming to use doesn't support it...