<tt>Daniel Veillard <veillard@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! > > </tt> <tt>[...] > > 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</tt> <tt>Future SR-IOV devices may be programmable and provide at least a subset </tt> <tt>of the filtering that can be done with this XML. In that case we would </tt> <tt>probably need hardware specific drivers in libvirt that can issue proper</tt> <tt>ioctl()s with the proper parameters to activate the corresponding filtering.</tt> <tt> > other case of limitiations could be found. Also this may not map well > for other kind of hypervisors like VMWare, right ?</tt> <tt>I don't know much about the API that VMWare is exposing. Maybe only a </tt> <tt>certain subset of what would be possible with this XML could be applied </tt> <tt>to their API, if such functionality exist. Otherwise, if libvirt</tt> <tt>can run ebtables and iptables commands on their management VM and</tt> <tt>all traffic passes through VM=specific network interface (tap) in that VM,</tt> <tt>it *should* work as well.</tt> <tt> > > > 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 ( > > </tt><a href=http://www.dmtf.org/standards/cim/cim_schema_v2230/CIM_Network.pdf><tt>http://www.dmtf.org/standards/cim/cim_schema_v2230/CIM_Network.pdf</tt></a><tt>, 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.</tt> <tt>Yes, we could do that. As said, this was meant as a draft.</tt> <tt> > > > <FilterEntry> > > <Action>DROP|ACCEPT</Action>  > > > > <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.</tt> <tt>Of course empty XML elements would not be shown. The above XML is meant </tt> <tt>to show all the network packet 'elements' that can be tested and for which </tt> <tt>also ebtables and iptables support exists. Also only a certain combination</tt> <tt>of the above elements would be set for a specific corresponding ebtables command.</tt> <tt>An example for a (template) XML for testing against MAC spoofing</tt> <tt>could be this XML here, which drops all IPv4 packets that don't have</tt> <tt>the proper MAC address set.</tt> <FilterEntry> <Action>DROP</Action> <TrafficType>outgoing</TrafficType> <Hdr8021Filter> <HdrSrcMACAddr8021>![THIS_MAC]</HdrSrcMACAddr8021> </Hdr8021Filter> <IPHeadersFilter> <HdrIPVersion>4</HdrIPVersion> </IPHeadersFilter> </FilterEntry> <tt> > > > 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.</tt> <tt>If we want to give the user full control over the ebtables and iptables features,</tt> <tt>an XML as the one above would be necessary. A more higher level XML may look as</tt> <tt>follows:</tt> <tt> <firewall> <no-mac-spoofing/> <no-ip-spoofing address="9.59.241.151"/> <ether-allow protocols='ARP,IPv4'/> [...] </firewall></tt> <tt>This XML only gives the user control over the features that have been</tt> <tt>explicitly implemented in libvirt, i.e., the driver would know what the</tt> <tt>corresponding ebtables commands are to enforce no-mac-spoofing, in which</tt> <tt>order the ebtable rules need to be organized and when to create new user defined</tt> <tt>ebtables (ebtables -N) to provide a more efficient evaluation of the filtering. </tt> <tt>The XSL trafo that Daniel Berrange mentioned would likely not be possible </tt> <tt>with this XML, since the ordering, depending on the chosen security features, may</tt> <tt>be tricky to support with a transformation.</tt> <tt>In the explicit XML above, the user would be expected to put the rules into </tt> <tt>proper order and likely would somehow need to provide user defined table names </tt> <tt>into which the individual rules need to be put. With this XML here, this would</tt> <tt>be automatically handled by the libvirt implementation.</tt> <tt>> > > 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.</tt> <tt>We thought that maybe the </tt>HdrSrcMACAddr8021<tt> XML element could have [THIS_MAC] </tt> <tt>as content, which would then need to become concrete when instantiated.</tt> <tt>Similarly we could put [THIS_IP] into the XML element testing for</tt> <tt>source (and destination) IP address. So the ip_address above would be</tt> <tt>passed into the function instantiating the rules for the VM.</tt> <tt> > > > > 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).</tt> <tt>It would work with any technology that uses an ethernet interface in </tt> <tt>the host, i.e., a tap or backend interface, through which all the VM's network </tt> <tt>traffic passes. All firewall rules would be conditioned on the VM's interface </tt> <tt>name and jump into a VM-specific rules tree.</tt> <tt>As for VirtualBox, since it is Qemu based and probably has a tap interface, </tt> <tt>this should also work. I have never used LXC, so I cannot say much about it,</tt> <tt>but it would also require a network interface in the host onto which</tt> <tt>ebtables and iptables could condition their rules on </tt> <tt>(ebtables -A ... -i <tap interface name> ...).</tt> <tt>One other thing to consider is whether pools should actually be used. The problem with</tt> <tt>the pools may arise when trying to migrate VMs. If the target host does not have</tt> <tt>the same named pool, then higher layer software would need to migrate the firewall rules</tt> <tt>first so the same rules can be enforced on the target as well. If, however, the rules </tt> <tt>are directly in the interface XML of the VM description, then migration would be </tt> <tt>done using 'virsh migrate', since the VM description migrates anyway.</tt> <tt>Regards,</tt> <tt> Stefan</tt> <tt> > 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 </tt><a href=http://xmlsoft.org/><tt>http://xmlsoft.org/</tt></a><tt> > daniel@veillard.com | Rpmfind RPM search engine </tt><a href=http://rpmfind.net/><tt>http://rpmfind.net/</tt></a><tt> > </tt><a href=http://veillard.com/><tt>http://veillard.com/</tt></a><tt> | virtualization library </tt><a href=http://libvirt.org/><tt>http://libvirt.org/</tt></a><tt> </tt>