[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] Libvirt and IPSec (was: What about Trusted Virtual Domains???)

On 04/29/2011 12:13 PM, Paolo Smiraglia wrote:
Hi to everyone!

Sorry for the latency of the response but me and my team we are noticed
that the TVD argument can not be treated only with a few lines in some
mails. In order to avoid any possible misunderstanding, we decided to
produce a little report (just four pages with images) that describes our
project. Technical details are not treated in the report. You can
download the report by using the link


Our idea is to start the discussion about Libvirt TVD implementation
using as starting point the report.

As already mentioned in previous mail, we think that the first step for
the implementation of the TVD is to make possible the 'tunnel' modeling
in Libvirt.

Considering the report, what do you think about our tunnel modeling
idea? It's right or some changes are needed?


Did you see my recent email titled "RFC: disconnecting guest/domain interface config from host config":


We both want to expand the usage of <network>, so we'd do well to avoid stepping on each others' toes! :-)

I'm wondering how the <sectunnel> element would fit in with network types that were not "bridge". I'm also curious about your work with openvswitch, because one of the potentials I can see as a result of expanding the usage of <network> is that openvswitch could be supported directly by libvirt by defining a new <network type='openvswitch'> (I mention that in one of the followup messages.

Also I'm still curious about my questions in my earlier response to you:


in particular:

1) does the network on each host always have a <forward ...> element for forwarding local traffic directly out to the public network? or alternately, is it possible to force a network on one host to send all traffic over the L2-over-L3 tunnel to a network on another machine, and from there out to the public network? It seems that, in this case, there would be no default route for the systems on the former network (in the case of no forwarding on a libvirt network, no default route is sent in the dhcp response - maybe that needs to be configurable...)

2) Is there an exact 1:1 correspondence between network and tunnel (or perhaps there may be multiple tunnels for a network, but those tunnels are not used by any other network on the same host)? If so, perhaps your project could be simplified by just putting the tunnel config as a subelement of <network>, rather than referencing it - this way you would avoid the need for the extra APIs to define/undefine/etc sectunnel.

3) Are your tunnels always L2, or do you have provision for setting up L3 tunnels? (Perhaps that could be done by allowing multiple <forward> elements, and having a <forward> that specified a tunnel rather than a physical interface, as well as a list of routes as subelements? This, along with a sectunnel subelement should be enough info to setup a secure L3 tunnel which would be used for the specified routes, right?

(BTW, after thinking about it some more, I think I agree that <network> is the right place to implement this, rather than a virInterface (host) based <interface> (although that would also be useful, totally separate from libvirt)).

It seems we can gain a lot from each other! I'm hoping to have my expansion of the network config completed by the end of June at latest, but your work may enable/force me to hurry it a bit more than that :-)
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]