On 10/25/2011 03:41 PM, David Stevens wrote:
Stefan Berger<stefanb@xxxxxxxxxxxxxxxxxx> 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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list