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

[Laine Stump]

On 04/06/2011 09:10 AM, Paolo Smiraglia wrote:
> Hi to everyone! First of all, sorry for the thread subject change.
>
> Due to the several issues of the Libvirt implementation of the Trusted 
> Virtual Domains (TVD), I decided to approach the topic in a modular 
> manner.
>
> I think that the first step should be to define the IPSec support or, 
> more in general, the secure tunnel support for Libvirt. I see the 
> implementation divided in two step:
>
>    1. define a new driver called 'sectunnel' which describes a generic
>       secure tunnel that will be established using several
>       technologies (for now using only ipsec)


Would this tunnel be necessarily brought up / torn down by libvirt, or 
could it be (maybe preferable? I don't have an opinion, just asking) 
that it be part of the host config, populating files in /etc. If the 
latter, maybe the right thing to do would be to enhance the XML of 
virInterfaceDefine (as described by netcf) to also configure ipsec 
tunnels (and openvpn tunnels, and whatever other tunnels)

(I mention this both as a possible way to avoid the need for a new 
libvirt API, as well as to enhance the functionality of virInterface*() 
and netcf)

Currently all traffic from the virtual networks is simply sent to the 
host's IP stack for forwarding. Are the decisions about which IPSec 
association to use for traffic based solely on routing, and is there 
necessarily a single routing domain on a host? Or can the decision be 
based on ipfilter rules and/or multiple routing domains on a single host 
(we had experimented with both of these at a former employer, but I 
don't recall which parts of it were local modifications and which were 
part of the stock kernel). If all decisions are based on routing, and 
there is a single routing domain, then the tunnel will necessarily be 
system-wide on the host, and may just as well be configured as any other 
interface (the only difference being that interfaces configured with 
virInterfaceDefine() persist even if libvirt is stopped and never 
started again, while something defined with virNetworkDefine (and 
probably a virSecTunnelDefine) may persist beyond stopping libvirt, but 
would not survive a reboot if libvirt wasn't started. A fine distinction 
actually, and maybe one that doesn't need to be made in general, but 
that's a different discussion)


>    2. modify the existing 'network' driver by adding the possibility to
>       specify the 'sectunnel' that
>       the network have to use in the virtual network definition


Will *all* traffic leaving/entering the virtual network travel via the 
tunnel, and will there be a single tunnel? If so, this could be given as 
a part of the <forward> element (similar to the way "dev='eth0'" is used 
now - it specifies that all traffic entering/leaving must go via eth0). 
It would look something like this:

<forward mode='route' tunnel='sec-net'/>

(of course all this really does is to set an ipfilter rule that 
disallows forwarding traffic to/from any other interface from/to the 
virtual network).

Beyond that, if there will an exact 1:1 correspondence between secure 
tunnel and virtual network (half of which is implied by the 
"tunnel='sec-net'"), perhaps the config for the tunnel could just be 
included in the <network> xml (probably as sub-elements of <forward>) 
rather than creating yet another API (and also the need to involve 
virInterface*()/netcf)


> As an example, you can see below a possible XML definition of the 
> network which use a secure tunnel and the corresponding 'sectunnel' 
> XML definition:
>
>     NETWORK DEFINITION
>     ==================
> <network>
> <name>sec-net</name>
> <uuid>3e3fce45-4f53-4fa7-bb32-11f34168b82b</uuid>
> <bridge name='virbr0' />
> <domain name='example' />
>     ...
> <sectunnel name='sec-tun' /> <--(specify the 'sectunnel' to use)
> </network>
>
>     SECTUNNEL DEFINITION
>     ====================
> <sectunnel type='ipsec'>
> <name>sec-tun</name>
> <uuid>8b7fd1b0-4463-43b7-8b6e-8006344aeb66</uuid>
>
> <!-- Security Association definitions -->
>
> <sa>
> <secret uuid='...' /> <--(specify the 'secret' which
>                                       contains the pre-shared key)
> </sa>
>
> <!-- Security Policy definitions -->
>
> <sp>
> <src_range address='10.0.0.1' prefixlen='30' port='5000' />
> <dst_range address='10.0.0.2' prefixlen='30' port='5000' />
> <upperspec protocol='any' />
>
> <policy direction='out' action='ipsec'>
> <rule protocol='esp' mode='tunnel' level='require'>
> <src address='192.168.0.1' port='55055' />
> <dst address='192.168.0.2' port='55055' />
> </rule>
> </policy>
> </sp>
>
> <sp>
> <src_range address='10.0.0.2' prefixlen='30' port='5000' />
> <dst_range address='10.0.0.1' prefixlen='30' port='5000' />
> <upperspec protocol='any' />
> <policy direction='in' action='ipsec'>
> <rule protocol='esp' mode='tunnel' level='require'>
> <src address='192.168.0.2' port='55055' />
> <dst address='192.168.0.1' port='55055' />
> </rule>
> </policy>
> </sp>
> </sectunnel>
>
> As you can see in the 'sectunnel' XML definition, I use a 'secret' 
> element. This element is a Libvirt secret [1] and it stores the 
> pre-shared key used by IPSec to establish the Security Associations 
> (SA). Obviously this feature requires to define a new usage category 
> in the 'secret' driver definition.
>
> Another possible way to establish the SA is to use the X.509 
> certificates. To this purpose, I think that the certificates already 
> used by Libvirt to setup SSL/TLS remote connections, might be used.
>
> That's all! :-)
>
> What do you think about this possible IPSec implementation?
>
> Thanks in advance for the replies!
>
> Best regards,
>
>    PAOLO
>
>
>
> LINK LIST
> ---------
> [1] http://libvirt.org/formatsecret.html
>
>
>
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list