On 03.09.2014 18:44, 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.
This is not problem for NBD only, but for the rest of data that qemu
sends over network, i.e. migration stream, VNC/SPICE, ...
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 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.
In case of libvirt, we have so called tunnelled migration (both spelled
& misspelled :P) in which libvirt opens a local ports on both src & dst
side and then sets up secured forwarding pipe to the other side. Or a
insecured one if user wishes so. The only problem is that when I adapted
libvirt for NBD, I intentionally forbade NBD in tunnelled migration as
it requires one more data stream for which libvirt migration protocol is
not ready yet. Having saidy that, I feel that libvirt is the show
stopper here, not QEMU.
I'm not saying that I'm against this. I've heard rumors that not
everybody out there uses libvirt and thus they might appreciate this
ability.
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.
Yep, that's how most of the secured protocols run. Somebody mentions
STARTTLS for which I vote as well.
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.
Michal