On Fri, Sep 05, 2014 at 12:02:18AM +0200, Wouter Verhelst wrote:
[Cc: to nbd-general list added]
On Wed, Sep 03, 2014 at 05:44:17PM +0100, Stefan Hajnoczi wrote:
Hi, QEMU offers both NBD client and server functionality. The NBD protocol runs unencrypted, which is a problem when the client and server communicate over an untrusted network.
The particular use case that prompted this mail is storage migration in OpenStack. The goal is to encrypt the NBD connection between source and destination hosts during storage migration.
I've never given encrypted NBD high priority, since I don't think encryption without authentication serves much purpose -- and I haven't gotten around to adding authentication yet (for which I have plans; but other things have priority).
While have an authentication layer like SASL wired into the NBD protocol would be nice, it shouldn't be considered a blocker / pre-requisite. It is pretty straightforward for the server to require x509 certificates from the client and validate those as a means of authentication. We've used that as an authentication mechanism in libvirt and VNC with success, though we did later add SASL integration as an option too.
I think we can integrate TLS into the NBD protocol as an optional flag. A quick web search does not reveal existing open source SSL/TLS NBD implementations. I do see a VMware NBDSSL protocol but there is no specification so I guess it is proprietary.
The NBD protocol starts with a negotiation phase. This would be the appropriate place to indicate that TLS will be used. After client and server complete TLS setup the connection can continue as normal.
Besides QEMU, the userspace NBD tools (http://nbd.sf.net/) can also be extended to support TLS. In this case the kernel needs a localhost socket and userspace handles TLS.
That introduces a possibility for a deadlock, since now your network socket isn't on the PF_MEMALLOC-protected socket anymore, which will cause the kernel to throw away packets which are needed for your nbd connection, in hopes of clearing some memory.
I suppose you could theoretically do the encryption in kernel space. Not convinced that trying TLS in kernel space is a good idea, though.
I have heard of people using stunnel or the likes to pipe the NBD protocol over a secure channel, with various levels of success.
Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|