[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



On 10/25/2011 03:41 PM, David Stevens wrote:
Stefan Berger<stefanb 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
The current (proposed) iterator does this, it produces every combination of IP and MAC list items. The question is whether this is the correct way of producing the filtering rules. On the one side one could say that the VM (or nested VMs) owns all the given MAC and IP addresses and can produce any combination of them. So we'll have m*n combinations -> O(n^2) evaluations. Another possibility would be to walk the lists of MAC and IP addresses parallel, i.e. produce a rule for $MAC[0] and $IP[0], another one for $MAC[n] and $IP[n], thus enforcing the association of IP and MAC addresses. We'd have O(n) evaluations, though the number of rules to evaluate should not drive how this works, but obviously 'correctness'. If we split the evaluation into two chains (one for IP , the other for MAC checking) we allow all combinations. Complexity is O(2*n) -> O(n).

So what should be correct?Fixed IP - MAC association or allow any combination of them? Maybe we leave it as proposed (two chains) for now and modify the iterator to process multiple lists' elements in parallel...
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.

Yes, fine. For backwards compatibility purposes the 'arp' chain will remain.
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.

With the arp chain remaining we can keep the existing filter 'allow-arp' and don't need the one proposed in this patch.
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.
I didn't test with a well-known DHCP server, so I was not sure whether the rule would actually be used. Following the DHCP protocol fields one could broadcast and put the IP address of the server into the server address field in the DHCP protocol and if the protocol was to support it that way only that server could respond

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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]