[libvirt] [RFC] Proposal for introduction of network traffic filtering capabilities for filtering of network traffic from and to VMs
Stefan Berger
stefanb at us.ibm.com
Wed Jan 13 21:42:23 UTC 2010
Daniel Veillard <veillard at redhat.com> wrote on 01/13/2010 12:03:22 PM:
> On Mon, Jan 11, 2010 at 12:55:27PM -0500, Stefan Berger wrote:
> > Hello!
> >
[...]
> > raw network throughput performance hit on their system due to the
> > evaluation of every packet passing through the filtering chains, do
not
> > have to use these capabilities. An initial implementation would be
done
> > for libvirt's Qemu support.
>
> It's relatively clear that this would not work with devices exposed
> natively to the domain, say though PCI passthough. I'm wondering what
Future SR-IOV devices may be programmable and provide at least a subset
of the filtering that can be done with this XML. In that case we would
probably need hardware specific drivers in libvirt that can issue proper
ioctl()s with the proper parameters to activate the corresponding
filtering.
> other case of limitiations could be found. Also this may not map well
> for other kind of hypervisors like VMWare, right ?
I don't know much about the API that VMWare is exposing. Maybe only a
certain subset of what would be possible with this XML could be applied
to their API, if such functionality exist. Otherwise, if libvirt
can run ebtables and iptables commands on their management VM and
all traffic passes through VM=specific network interface (tap) in that VM,
it *should* work as well.
>
> > As stated above, the application of firewall rules on virtual machines
> > will require some form of XML description that lets the user choose
what
> > type of filtering is to be performed. In effect the user needs to be
able
> > to tell libvirt which ebtables and iptables rules to generate so that
the
> > appropriate filtering can be done. We realize that ebtables and
iptables
> > have lots of capabilities but think that we need to restrict which
> > capabilities can actually be 'reached' through this XML.
> >
> > The following proposal is based on an XML as defined by the DMTF (
> > http://www.dmtf.org/standards/cim/cim_schema_v2230/CIM_Network.pdf,
slide
> > 10) with extensions for processing of ARP packets.It gives control
over
> > the evaluation of Ethernet (MAC) frames, ARP packet data and IP header
> > information. A (draft) XML skeleton in this case could look as
follows:
>
> Humpf, extending astandard XML schemas is really bad practice. Even if
> you think that the extension may be accepted later, it may have
> different semantic for the same construct and that's a disaster.
> I would at least put the new elements in a separate namespace to
> avoid something insane if DMTF extends its specification.
Yes, we could do that. As said, this was meant as a draft.
>
> > <FilterEntry>
> > <Action>DROP|ACCEPT</Action> <!-- from FilterEntry -->
> >
> > <TrafficType>incoming [to VM]|outgoing [from VM]</TrafficType>
> >
> > <Hdr8021Filter>
> > <HdrSrcMACAddr8021> </HdrSrcMACAddr8021>
> > <HdrSrcMACMask8021> </HdrSrcMACMask8021>
> > <HdrDestMACAddr8021> </HdrDestMACAddr8021>
> > <HdrDestMACMask8021> </HdrDestMACMask8021>
> > <HdrProtocolID8021> numeric and/or string?
> > </HdrProtocolID8021>
> > <HdrPriorityValue8021></HdrPriorityValue8021>
> > <HdrVLANID8021> </HdrVLANID8021>
> > </Hdr8021Filter>
> >
> > <ARPFilter>
> > <HWType> </HWType>
> > <ProtocolType> </ProtocolType>
> > <OPCode> </OPCode>
> > <SrcMACAddr> </SrcMACAddr>
> > <SrcIPAddr> </SrcIPAddr>
> > <DestMACAddr> </DestMACAddr>
> > <DestIPAddr> </DestIPAddr>
> > </ARPFilter>
> >
> > <IPHeadersFilter>
> > <HdrIPVersion> </HdrIPVersion>
> > <HdrSrcAddress> </HdrSrcAddress>
> > <HdrSrcMask> </HdrSrcMask>
> > <HdrDestAddress> </HdrDestAddress>
> > <HdrDestMask> </HdrDestMask>
> > <HdrProtocolID> numeric and/or string?
</HdrProtocolID>
> > <HdrSrcPortStart> </HdrSrcPortStart>
> > <HdrSrcPortEnd> </HdrSrcPortEnd>
> > <HdrDestPortStart> </HdrDestPortStart>
> > <HdrDestPortEnd> </HdrDestPortEnd>
> > <HdrDSCP> </HdrDSCP>
> > </IPHeadersFilter>
> >
> > </FilterEntry>
>
> hum the types for each values should be made explicit if possible,
> But in general I find that extremely bulky for a single entry, while
> I would expect any domain to have a dozen filters or so just for
> simple stuff. I wonder if empty default should just be dropped, so
> that basically if you're filtering on a MAC address you don't carry
> a bunch of unused fields.
Of course empty XML elements would not be shown. The above XML is meant
to show all the network packet 'elements' that can be tested and for which
also ebtables and iptables support exists. Also only a certain combination
of the above elements would be set for a specific corresponding ebtables
command.
An example for a (template) XML for testing against MAC spoofing
could be this XML here, which drops all IPv4 packets that don't have
the proper MAC address set.
<FilterEntry>
<Action>DROP</Action>
<TrafficType>outgoing</TrafficType>
<Hdr8021Filter>
<HdrSrcMACAddr8021>![THIS_MAC]</HdrSrcMACAddr8021>
</Hdr8021Filter>
<IPHeadersFilter>
<HdrIPVersion>4</HdrIPVersion>
</IPHeadersFilter>
</FilterEntry>
>
> > Since the ebtables and iptables command cannot accept all possible
> > parameters at the same time, only a certain subset of the above
parameters
> > may be set for any given filter command. Higher level application
writers
> > will likely use a library that lets them choose which features they
would
> > want to have enforced, such as no-broadcast or no-multicast,
enforcement
> > of MAC spoofing prevention or ARP poisoning prevention, which then
> > generates this lower level XML rules in the appropriate order of the
> > rules.
>
> I wonder if a tailored set of simpler XML matching what is actually
> possible and getting away from the DMTF records wouldn't be better,
> since the original spec is extended on the feature side and the
> applicability is restricted on the implementation side, I'm not sure I
> see the point of trying to be compatible.
If we want to give the user full control over the ebtables and iptables
features,
an XML as the one above would be necessary. A more higher level XML may
look as
follows:
<firewall>
<no-mac-spoofing/>
<no-ip-spoofing address="9.59.241.151"/>
<ether-allow protocols='ARP,IPv4'/>
[...]
</firewall>
This XML only gives the user control over the features that have been
explicitly implemented in libvirt, i.e., the driver would know what the
corresponding ebtables commands are to enforce no-mac-spoofing, in which
order the ebtable rules need to be organized and when to create new user
defined
ebtables (ebtables -N) to provide a more efficient evaluation of the
filtering.
The XSL trafo that Daniel Berrange mentioned would likely not be possible
with this XML, since the ordering, depending on the chosen security
features, may
be tricky to support with a transformation.
In the explicit XML above, the user would be expected to put the rules
into
proper order and likely would somehow need to provide user defined table
names
into which the individual rules need to be put. With this XML here, this
would
be automatically handled by the libvirt implementation.
>
> > Further, we will introduce filter pools where a collection of the
above
> > filter rules can be stored and referenced to by virtual machines'
> > individual interface. A reference to such a filter pool entry will be
> > given in the interface description and may look as in the following
draft
> > XML:
> >
> > <interface type='bridge'>
> > <source bridge='virbr0'/>
> > <script path='vif-bridge'/>
> > <firewall>
> > <reference profile='generic-layer2' ip_address='10.0.0.1'/>
> > <reference profile='VM-specific-layer3'/>
> > </firewall>
> > </interface>
>
> the devil is in the details, basically how you would template
> the profiles based on the strings in the reference. I.e. what the
> profile would look like and how for example ip_address='10.0.0.1'
> would be instancied in the profile use.
We thought that maybe the HdrSrcMACAddr8021 XML element could have
[THIS_MAC]
as content, which would then need to become concrete when instantiated.
Similarly we could put [THIS_IP] into the XML element testing for
source (and destination) IP address. So the ip_address above would be
passed into the function instantiating the rules for the VM.
> >
> > Further, we would introduce the management of filter 'pools'.
Considering
> > existing functionality in libvirt and CLI commands for similar type of
> > management functionality, the following CLI commands would be added:
> >
> > virsh nwfilter-create <file>
> > virsh nwfilter-destroy <profile name>
> > virsh nwfilter-list <options>
> > virsh nwfilter-dumpxml <profile name>
> > virsh nwfilter-update <filename> (performs an update on an
existing
> > profile replacing all rules)
> >
> > possibly also:
> >
> > virsh nwfilter-edit <profile name>
> > virsh nwfilter-create-from <profile name>
> >
> >
> > Please let us know what you think of this proposal.
>
> The feature looks interesting ! It looks it should be applicable to
> at least qemu and xen, I'm not so sure about LXC or VirtualBox, and
> looks unlikely for VMWare unless they have a matching capability (might
> be possible since it's based at least partly on DMTF).
It would work with any technology that uses an ethernet interface in
the host, i.e., a tap or backend interface, through which all the VM's
network
traffic passes. All firewall rules would be conditioned on the VM's
interface
name and jump into a VM-specific rules tree.
As for VirtualBox, since it is Qemu based and probably has a tap
interface,
this should also work. I have never used LXC, so I cannot say much about
it,
but it would also require a network interface in the host onto which
ebtables and iptables could condition their rules on
(ebtables -A ... -i <tap interface name> ...).
One other thing to consider is whether pools should actually be used. The
problem with
the pools may arise when trying to migrate VMs. If the target host does
not have
the same named pool, then higher layer software would need to migrate the
firewall rules
first so the same rules can be enforced on the target as well. If,
however, the rules
are directly in the interface XML of the VM description, then migration
would be
done using 'virsh migrate', since the VM description migrates anyway.
Regards,
Stefan
> I'm not sure reusing the DMTF format actually helps much, it also has
> its risks due to the extension.
>
> Daniel
>
> --
> Daniel Veillard | libxml Gnome XML XSLT toolkit
http://xmlsoft.org/
> daniel at veillard.com | Rpmfind RPM search engine http://rpmfind.net/
> http://veillard.com/ | virtualization library http://libvirt.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20100113/1ca006db/attachment-0001.htm>
More information about the libvir-list
mailing list