Re: [libvirt] [RFC] Proposal for introduction of network traffic filtering capabilities for filtering of network traffic from and to VMs

On Mon, Jan 11, 2010 at 12:55:27PM -0500, Stefan Berger wrote: > 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. > <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. > 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.