[libvirt] [RFC][PATCH]: Secure migration

[Daniel Veillard]

On Mon, Mar 16, 2009 at 04:26:58PM +0100, Chris Lalancette wrote:
> All,
>      Attached is a *very* rough first draft of the secure migration code I'm
> working on.  This is in no way ready for merge.  That being said, this
> demonstrates the basic idea that I'm pursuing, and I've actually been able to
> perform a KVM secure live migrate using this.  Before I go and finish polishing
> it up, though, I wanted to make sure there wasn't anything fundamentally wrong
> with the approach.  So, in that vein, comments are appreciated.

> diff --git a/qemud/remote_protocol.h b/qemud/remote_protocol.h
> index 75def5e..d97a18b 100644
> --- a/qemud/remote_protocol.h
> +++ b/qemud/remote_protocol.h
> @@ -41,6 +41,8 @@ typedef remote_nonnull_string *remote_string;
>  #define REMOTE_SECURITY_MODEL_MAX VIR_SECURITY_MODEL_BUFLEN
>  #define REMOTE_SECURITY_LABEL_MAX VIR_SECURITY_LABEL_BUFLEN
>  #define REMOTE_SECURITY_DOI_MAX VIR_SECURITY_DOI_BUFLEN
> +#define REMOTE_CONNECT_SECURE_MIGRATION_DATA_MAX 65536
> +#define REMOTE_CONNECT_SECURE_MIGRATION_COOKIE_MAX 65536
>  
>  typedef char remote_uuid[VIR_UUID_BUFLEN];
>  

  Okay I have tried to think again about this, from the code fragment
before and discussions on IRC while performances are tolerable, there
is a lot of costs related to the 64KB chunking imposed by the XML-RPC.
  It is probably acceptable for a class of users who really want
encryption of their data but I would like to make sure we don't close
the door for a possibly more performant implementation.
  Trying to reopen a bit the discussion we had before on opening a
separate encrypted connection, this would have a number of potential
improvements over the XML-RPC:
   - no chunking, far less context-switching (it would be good to know
     how much of excess time spent in the secure migration is data
     encoding, how much is overall system burden)
   - seems to me a more standard encrypted TCP/IP connection would be
     more likely to be able to reuse crypto hardware if/when they get
     available.
  My main concern is keeping a port open in the firewall for the
incoming connection of the encrypted data, and I wonder if it's really
necessary, basically since the receiver and the sender can both
communicate already via the XML-RPC maybe something like STUN (for UDP)
where both end open simultaneously a new connection to the other side
might work, and that can be coordinated via the XML-RPC (passing the new
port opened etc). The point being that usually firewall block only
incoming connections to non-registered port but outcoming connections
are allowed to go, I have no idea if this can be made to work though.
  In general I would like to make sure we have room in the initial phase
to add such a negociation where an optimal solution may be attempted,
possibly falling back to a normal XML-RPC solution like this.
Basically, make sure we can try to be as efficient as possible, and
allow the protocol to evolve, but fallback to XML-RPC encapsulation
if that initial round fails.

  any though ?

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/