[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/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 redhat com
https://www.redhat.com/mailman/listinfo/libvir-list


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