[libvirt] [PATCH 2/9] add DHCP snooping support to nwfilter
The ARP protocol requires processing of packets that may not be explicitly addressed to a host and only defines request and reply. This patch removes the filtering of gratuitous ARPs and ARP requests which must update a VMs patch for correct function and removes the unnecessary check for arpop of request or reply. Signed-off-by: David L Stevens <dlstevens@us.ibm.com> diff --git a/examples/xml/nwfilter/no-arp-spoofing.xml b/examples/xml/nwfilter/no-arp-spoofing.xml index c6c858d..fdd4e60 100644 --- a/examples/xml/nwfilter/no-arp-spoofing.xml +++ b/examples/xml/nwfilter/no-arp-spoofing.xml @@ -12,21 +12,6 @@ <rule action='drop' direction='out' priority='400' > <arp match='no' arpsrcipaddr='$IP' /> </rule> - <!-- drop if ipaddr or macaddr odes not belong to guest --> - <rule action='drop' direction='in' priority='450' > - <arp match='no' arpdstmacaddr='$MAC'/> - <arp opcode='reply'/> - </rule> - <rule action='drop' direction='in' priority='500' > - <arp match='no' arpdstipaddr='$IP' /> - </rule> - <!-- accept only request or reply packets --> - <rule action='accept' direction='inout' priority='600' > - <arp opcode='request'/> - </rule> - <rule action='accept' direction='inout' priority='650' > - <arp opcode='reply'/> - </rule> <!-- drop everything else --> - <rule action='drop' direction='inout' priority='1000' /> + <rule action='drop' direction='out' priority='1000' /> </filter>
On 05/09/2011 04:02 PM, David L Stevens wrote:
The ARP protocol requires processing of packets that may not be explicitly addressed to a host and only defines request and reply. This patch removes the filtering of gratuitous ARPs and ARP requests which must update a VMs patch for correct function and removes the unnecessary check for arpop of request or reply. As for the gratuitous ARPs I believe what's missing is the usage of 'ebtables ... -p ARP --arp-gratuitous' which presumably then lets the VM see the gratuitous ARP packets. This would then add
<rule action='accept' direction='in' priority='425'> <arp gratuitous='true'/> </rule> to the list below. I have a patch for that now, which is needed in any case. For the other ARP requests I am not sure whether the VM needs to see all of them. If a VM sees an ARP request on an interface not directed for any of its IP addresses, why deliver the request at all? The VM cannot respond to it. Since we are filtering on ARP we may just as well drop it which likely saves a few processing cycles in the whole system. So I wouldn't remove the filtering. Stefan
Signed-off-by: David L Stevens<dlstevens@us.ibm.com>
diff --git a/examples/xml/nwfilter/no-arp-spoofing.xml b/examples/xml/nwfilter/no-arp-spoofing.xml index c6c858d..fdd4e60 100644 --- a/examples/xml/nwfilter/no-arp-spoofing.xml +++ b/examples/xml/nwfilter/no-arp-spoofing.xml @@ -12,21 +12,6 @@ <rule action='drop' direction='out' priority='400'> <arp match='no' arpsrcipaddr='$IP' /> </rule> -<!-- drop if ipaddr or macaddr odes not belong to guest --> -<rule action='drop' direction='in' priority='450'> -<arp match='no' arpdstmacaddr='$MAC'/> -<arp opcode='reply'/> -</rule> -<rule action='drop' direction='in' priority='500'> -<arp match='no' arpdstipaddr='$IP' /> -</rule> -<!-- accept only request or reply packets --> -<rule action='accept' direction='inout' priority='600'> -<arp opcode='request'/> -</rule> -<rule action='accept' direction='inout' priority='650'> -<arp opcode='reply'/> -</rule> <!-- drop everything else --> -<rule action='drop' direction='inout' priority='1000' /> +<rule action='drop' direction='out' priority='1000' /> </filter>
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Stefan Berger <stefanb@linux.vnet.ibm.com> wrote on 05/23/2011 01:09:51 PM:
For the other ARP requests I am not sure whether the VM needs to see all
of them. If a VM sees an ARP request on an interface not directed for any of its IP addresses, why deliver the request at all? The VM cannot respond to it. Since we are filtering on ARP we may just as well drop it
which likely saves a few processing cycles in the whole system. So I wouldn't remove the filtering.
No, the point is to update cached entries. If some some other machine does an ARP request or reply (either) that updates an entry in our ARP cache, we are supposed to do that. From RFC 826: ... If the pair <protocol type, sender protocol address> is already in my translation table, update the sender hardware address filed of the entry with the new information in the packet and set Merge_flag to true. ?Am I the target protocol address? See, it updates the cache before even checking if we are the target. +-DLS
participants (3)
-
David L Stevens -
David Stevens
-
Stefan Berger