[libvirt] [libvirt PATCHv3 03/10] reverse sense of address matching

[David Stevens]

Stefan Berger <stefanb at linux.vnet.ibm.com> wrote on 10/25/2011 12:01:05 
PM:

> So the intention here was to remove the 'arp' chain. With it staying now 

> I suppose this patch and the allow-arpmac and allow-arpip aren't needed.
> > diff --git a/examples/xml/nwfilter/allow-arpip.xml b/examples/xml/
> nwfilter/allow-arpip.xml

The intention was to separate MAC and IP address matching to be their
own chains to make adding and removing addresses dynamically easy. If you
do this in one chain with "IP=X and MAC=Y -j ACCEPT", then you need
every combination of IP and MAC address as a rule. If you separate them
into MAC matching and protocol matching chains, you need one rule
per MAC and IP address. After doing that, the ARP chain was empty, since
that's all the standard chain had.

> > new file mode 100644
> > index 0000000..6ddb6fe
> > --- /dev/null
> > +++ b/examples/xml/nwfilter/allow-arpip.xml
> > @@ -0,0 +1,3 @@
> > +<filter name='allow-arpip' chain='arpip'>
> > +<rule direction='inout' action='accept'/>
> > +</filter>
> Seems no necessary following above.

I don't understand this comment.

> This reshuffeling might make it more intuitive but isn't necessary.

I didn't say it was the only way to support multiple addresses. :-)
It uses nMAC + nIP rules, instead of nMAC X nIP rules to match every
combination of MAC and IP addresses in the original ARP chain.

> > +</rule>
> > +<rule action='return' direction='out' priority='410'>
> > +<arp match='yes' arpsrcipaddr='0.0.0.0' />
> > +</rule>
> Under what circumstances is the stack allowed to send a 0.0.0.0 as a 
> response to an ARP request (presumably)? Form what I see 0.0.0.0 could 
> be any machine whose interface is not configured. At least when using 
> DHCP the VM would broadcast the request without prior sending of an ARP 
> request (of course) and from what I remember the DHCP server then sends 
> the response back to the MAC address it has received the request from 
> also without ARP request.

This isn't a requirement, but in general, the filters are placing
restrictions on packets that have nothing to do with spoofing and are
not part of the underlying protocols. A host without an IP address
can use source address "0.0.0.0" legally by the protocols in cases besides
sending a DHCP request, DHCP requests need not be MAC broadcast or sent
to the all-hosts broadcast address (e.g., if firmware configured a 
particular
preferred server (unicast MAC and/or IP), or knows the subnet and uses
a directed broadcast). ARP requests received from other machines need
not be addressed to this VM to be processed and update the cache.

By restricting these cases, the filters prevent VMs from doing
protocol-legal things that have nothing to do with spoofing. It simply
breaks unusual configurations unnecessarily.

I was planning to submit clean-up patches to remove all these
restrictions I found after my primary concern (DHCP snooping) is done.
I threw in some of them along with the multiple address support in
the version that did that, but they really are separate fixes that
have nothing to do with either multiple address support or DHCP
snooping.

In the end, base anti-spoofing rules should prevent a VM from
masquerading as someone else, and allow everything else.

                                                                +-DLS