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