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

[Laine Stump]

On 04/29/2011 01:32 PM, Laine Stump wrote:
> 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
>>
>>     http://dl.dropbox.com/u/824617/tvd_in_libvirt.pdf
>>
>> 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?
>
> Paolo,
>
> Did you see my recent email titled "RFC: disconnecting guest/domain 
> interface config from host config":
>
>   https://www.redhat.com/archives/libvir-list/2011-April/msg00591.html

And more discussion on the same topic that unfortunately got put into a 
different thread:

   https://www.redhat.com/archives/libvir-list/2011-April/msg01269.html

Please let me know how sectunnel stuff would fit in with that.

>
> 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:
>
>   https://www.redhat.com/archives/libvir-list/2011-April/msg00589.html
>
> 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 :-)
> -- 
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
>