----- Original Message ----- > From: "Andrew Cathrow" <[email protected]> > To: "Mark Wu" <[email protected]> > Cc: [email protected], "Michal Skrivanek" <[email protected]> > Sent: Friday, January 11, 2013 2:28:27 PM > Subject: Re: tunnelled migration > > > > ----- Original Message ----- > > From: "Mark Wu" <[email protected]> > > To: "Caitlin Bestler" <[email protected]> > > Cc: "Michal Skrivanek" <[email protected]>, [email protected] > > Sent: Friday, January 11, 2013 1:05:10 AM > > Subject: Re: tunnelled migration > > > > On 01/11/2013 04:14 AM, Caitlin Bestler wrote: > > > Dan Kenisberg wrote: > > > > > > > > >> Choosing tunnelled migration is thus a matter of policy. I would > > >> like to suggest a new cluster-level configurable in Engine, > > >> that controls whether migrations in this cluster are tunnelled. > > >> The configurable must be available only in new cluster levels > > >> where hosts support it. > > > Why not just dump this issue to network configuration? > > > > > > Migrations occur over a secure network. That security could be > > > provided by port groups, VLANs or encrypted tunnels. > > Agreed. Is a separate vlan network not secure enough? If yes, we > > could > > build a virtual encrypted network, like using openvpn + iptables. > > While I agree that a vlan should be enough, and that's their purpose > we've learned from downstream customers that this isn't enough and > their security teams require all traffic to be encrypted.
In time we go from hardware enforced security to application enforced security. At the end what we really need to do is to stop messing with network configuration and add cryptographic lan to qemu, so that every virtual nic will encrypt the traffic using key based on destination. The key for destination will be acquired from central key manager, much like kerberos (if not kerberos). This will enable a totally flat network (either layer 2 or layer 3) and have total virtual cryptographic based virtual network over that. Regards, Alon Bar-Lev. _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
