Re: [libvirt] [libvirt PATCHv3 00/10] DHCP snooping support for libvirt
On 10/12/2011 05:25 PM, David Stevens wrote: Stefan Bergerstef...@linux.vnet.ibm.com wrote on 10/12/2011 02:02:59 PM: The problem we're having at the moment is that it's not possible to evaluate fields of packets that may have more than one possible value. This is the general problem, the specific one being allowing multiple MAC or IP addresses. Stefan, Yes, this is why for this patchset I've added RETURN and made the address checks be if match return and a default drop at the end. This code already supports multiple IP addresses for DHCP snooping, static IP addresses (new to this version) and a combination of the two (if both IP is set and ip_learning=dhcp. Sample output using multiple static addresses below. The same model can be applied to user-generated filters with: do a series of checks using RETURN for acceptable packets -j DROP If the user filter does RETURN, it'll apply other tests as well. If it does ACCEPT/DROP, it'll accept or drop despite any other conditions. I'm not sure I see any need for other tables here, though-- can you elaborate? +-DLS Basically I would like to get away from having a hardcoded representation of the names of filters inside the code. We now have 4 such filters, arp, rarp, ipv4 and ipv6 and you are adding 2 more arpmac and arpip. For ipv6 we would again need to add more. I think the names of the filters should be picked up from the XML and then in some way sorted and have them generate the rules -j I-vnet0-mac -p IPv4 -j I-vnet0-ipv4 -p ARP -j I-vnet0-arpmac -p ARP -j I-vnet0-arpip -p 0x8035 -j I-vnet0-rarp in the right order. i.e., ipv4 before ipv6 before arpmac before arpip before rapr and 'arp' somewhere in between. This and later on an introduction of an action 'jump' or 'goto' with a target would then provide more flexibility for the user to build even more complex filters. I'll look into getting rid of the bit fields that I have been using so far and try to collect the names of filters. I guess they would have to be given an implicit 'priority' so they are ordered in that way above -- so maybe some of the filters are known to the system and have an implicit priority while others will have to be given a priority. Comments? Stefan lab1.dls 226 # ebtables -t nat -L Bridge table: nat Bridge chain: PREROUTING, entries: 1, policy: ACCEPT -i vnet0 -j libvirt-I-vnet0 Bridge chain: OUTPUT, entries: 0, policy: ACCEPT Bridge chain: POSTROUTING, entries: 1, policy: ACCEPT -o vnet0 -j libvirt-O-vnet0 Bridge chain: libvirt-I-vnet0, entries: 9, policy: ACCEPT -j I-vnet0-mac -p IPv4 -j I-vnet0-ipv4 -p ARP -j I-vnet0-arpmac -p ARP -j I-vnet0-arpip -p 0x8035 -j I-vnet0-rarp -p 0x835 -j ACCEPT -p IPv4 -j ACCEPT -p ARP -j ACCEPT -j DROP Bridge chain: libvirt-O-vnet0, entries: 5, policy: ACCEPT -p IPv4 -j O-vnet0-ipv4 -p 0x8035 -j O-vnet0-rarp -p IPv4 -j ACCEPT -p ARP -j ACCEPT -j DROP Bridge chain: I-vnet0-mac, entries: 1, policy: DROP -s 54:0:0:0:0:1 -j RETURN Bridge chain: I-vnet0-ipv4, entries: 5, policy: DROP -p IPv4 --ip-src 10.0.0.1 -j RETURN -p IPv4 --ip-src 0.0.0.0 --ip-proto udp --ip-sport 68 -j RETURN -p IPv4 --ip-src 11.0.0.0/24 -j RETURN -p IPv4 --ip-src 10.0.0.3 -j RETURN -p IPv4 --ip-src 10.0.0.4 -j RETURN Bridge chain: O-vnet0-ipv4, entries: 1, policy: DROP -j ACCEPT Bridge chain: I-vnet0-arpmac, entries: 1, policy: DROP -p ARP --arp-mac-src 54:0:0:0:0:1 -j RETURN Bridge chain: I-vnet0-arpip, entries: 5, policy: DROP -p ARP --arp-ip-src 10.0.0.1 -j RETURN -p ARP --arp-ip-src 0.0.0.0 -j RETURN -p ARP --arp-ip-src 11.0.0.0/24 -j RETURN -p ARP --arp-ip-src 10.0.0.3 -j RETURN -p ARP --arp-ip-src 10.0.0.4 -j RETURN Bridge chain: I-vnet0-rarp, entries: 1, policy: DROP -p 0x8035 -s 54:0:0:0:0:1 -d Broadcast --arp-op Request_Reverse --arp-ip-src 0.0.0.0 --arp-ip-dst 0.0.0.0 --arp-mac-src 54:0:0:0:0:1 --arp-mac-dst 54:0:0:0:0:1 -j ACCEPT Bridge chain: O-vnet0-rarp, entries: 1, policy: DROP -p 0x8035 -d Broadcast --arp-op Request_Reverse --arp-ip-src 0.0.0.0 --arp-ip-dst 0.0.0.0 --arp-mac-src 54:0:0:0:0:1 --arp-mac-dst 54:0:0:0:0:1 -j ACCEPT -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [libvirt PATCHv3 00/10] DHCP snooping support for libvirt
David,
I have unfortunately missed v2 of this and in the meantime (since
after V1) I had been thinking about this a bit.
The problem we're having at the moment is that it's not possible to
evaluate fields of packets that may have more than one possible value.
This is the general problem, the specific one being allowing multiple
MAC or IP addresses. This problem requires us to enable more tables
along with jumps to those tables. I think we should solve this in a more
general way. What we seem to need for this are tables that are connected
to the 'root table' of an interface and tables that are not connected to
the 'root table'. So for now we handle arp, rarp, ipv4 and ipv6 from
that 'root' table using '-p arp -j table' for example to jump to an
ARP-specific table for example, the protocol being the decision point
here ('-p'). So now maybe what we should do is allow user to define
tables with prefixes 'arp', 'ipv4' and 'ipv6' and have all of them
connected to the root table and jump into them using '-p'. There could
be an arp table, an 'arp-xyz' table and all of them would be connected
to that root table -- the question is just in what order. Maybe
alphabetical order, with arp and rarp still being always treated after
ipv4 and ipv6. Then to realize the other 'loose tables' they could maybe
all be required to have a prefix 'ud-' for 'user-defined'. Those would
then just be created but not accessed from the 'root table' of an
interface but from those connected to an interface's 'root table'. Does
this sound reasonable ?
Stefan
On 10/12/2011 03:50 PM, David L Stevens wrote:
This series of patches adds DHCP snooping support to libvirt. This version
saves leases on disk for restoration after a libvirtd restart and allows
selection of different ip_learning methods by setting filter parameter
ip_learning to one of any (existing IP learning code) none (static only
addresses) or DHCP (DHCP Snooping).
This code does not (yet) support passing lease information across a migration.
A migrated guest requires a DHCP ACK (e.g., via ifdown/ifup on the guest) to
send/receive traffic for DHCP-learned addresses after a migration.
Differences from v2: added support for multiple static IP addresses using
a comma-separated list.
David L Stevens (10):
support continue/return
allow required ARP packets
reverse sense of address matching
make default chain policy DROP
allow chain modification
support addRules
support variable value changing
add DHCP snooping
add leasefile support
support multiple static IP addresses
examples/xml/nwfilter/Makefile.am |5 +-
examples/xml/nwfilter/allow-arp.xml |5 +-
examples/xml/nwfilter/allow-arpip.xml |3 +
examples/xml/nwfilter/allow-arpmac.xml |3 +
examples/xml/nwfilter/clean-traffic.xml |6 +-
examples/xml/nwfilter/no-arp-spoofing.xml | 38 +-
examples/xml/nwfilter/no-arpip-spoofing.xml | 10 +
examples/xml/nwfilter/no-arpmac-spoofing.xml|5 +
examples/xml/nwfilter/no-ip-spoofing.xml|9 +-
examples/xml/nwfilter/no-mac-spoofing.xml | 10 +-
examples/xml/nwfilter/no-other-l2-traffic.xml | 13 +-
examples/xml/nwfilter/no-other-rarp-traffic.xml |3 -
examples/xml/nwfilter/qemu-announce-self.xml|1 -
src/Makefile.am |2 +
src/conf/nwfilter_conf.c| 12 +-
src/conf/nwfilter_conf.h| 16 +-
src/nwfilter/nwfilter_dhcpsnoop.c | 938 +++
src/nwfilter/nwfilter_dhcpsnoop.h | 36 +
src/nwfilter/nwfilter_driver.c |5 +
src/nwfilter/nwfilter_ebiptables_driver.c | 225 +--
src/nwfilter/nwfilter_gentech_driver.c | 225 +-
src/nwfilter/nwfilter_gentech_driver.h | 11 +
22 files changed, 1445 insertions(+), 136 deletions(-)
create mode 100644 examples/xml/nwfilter/allow-arpip.xml
create mode 100644 examples/xml/nwfilter/allow-arpmac.xml
create mode 100644 examples/xml/nwfilter/no-arpip-spoofing.xml
create mode 100644 examples/xml/nwfilter/no-arpmac-spoofing.xml
delete mode 100644 examples/xml/nwfilter/no-other-rarp-traffic.xml
create mode 100644 src/nwfilter/nwfilter_dhcpsnoop.c
create mode 100644 src/nwfilter/nwfilter_dhcpsnoop.h
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [libvirt PATCHv3 00/10] DHCP snooping support for libvirt
Stefan Berger stef...@linux.vnet.ibm.com wrote on 10/12/2011 02:02:59 PM: The problem we're having at the moment is that it's not possible to evaluate fields of packets that may have more than one possible value. This is the general problem, the specific one being allowing multiple MAC or IP addresses. Stefan, Yes, this is why for this patchset I've added RETURN and made the address checks be if match return and a default drop at the end. This code already supports multiple IP addresses for DHCP snooping, static IP addresses (new to this version) and a combination of the two (if both IP is set and ip_learning=dhcp. Sample output using multiple static addresses below. The same model can be applied to user-generated filters with: do a series of checks using RETURN for acceptable packets -j DROP If the user filter does RETURN, it'll apply other tests as well. If it does ACCEPT/DROP, it'll accept or drop despite any other conditions. I'm not sure I see any need for other tables here, though-- can you elaborate? +-DLS lab1.dls 226 # ebtables -t nat -L Bridge table: nat Bridge chain: PREROUTING, entries: 1, policy: ACCEPT -i vnet0 -j libvirt-I-vnet0 Bridge chain: OUTPUT, entries: 0, policy: ACCEPT Bridge chain: POSTROUTING, entries: 1, policy: ACCEPT -o vnet0 -j libvirt-O-vnet0 Bridge chain: libvirt-I-vnet0, entries: 9, policy: ACCEPT -j I-vnet0-mac -p IPv4 -j I-vnet0-ipv4 -p ARP -j I-vnet0-arpmac -p ARP -j I-vnet0-arpip -p 0x8035 -j I-vnet0-rarp -p 0x835 -j ACCEPT -p IPv4 -j ACCEPT -p ARP -j ACCEPT -j DROP Bridge chain: libvirt-O-vnet0, entries: 5, policy: ACCEPT -p IPv4 -j O-vnet0-ipv4 -p 0x8035 -j O-vnet0-rarp -p IPv4 -j ACCEPT -p ARP -j ACCEPT -j DROP Bridge chain: I-vnet0-mac, entries: 1, policy: DROP -s 54:0:0:0:0:1 -j RETURN Bridge chain: I-vnet0-ipv4, entries: 5, policy: DROP -p IPv4 --ip-src 10.0.0.1 -j RETURN -p IPv4 --ip-src 0.0.0.0 --ip-proto udp --ip-sport 68 -j RETURN -p IPv4 --ip-src 11.0.0.0/24 -j RETURN -p IPv4 --ip-src 10.0.0.3 -j RETURN -p IPv4 --ip-src 10.0.0.4 -j RETURN Bridge chain: O-vnet0-ipv4, entries: 1, policy: DROP -j ACCEPT Bridge chain: I-vnet0-arpmac, entries: 1, policy: DROP -p ARP --arp-mac-src 54:0:0:0:0:1 -j RETURN Bridge chain: I-vnet0-arpip, entries: 5, policy: DROP -p ARP --arp-ip-src 10.0.0.1 -j RETURN -p ARP --arp-ip-src 0.0.0.0 -j RETURN -p ARP --arp-ip-src 11.0.0.0/24 -j RETURN -p ARP --arp-ip-src 10.0.0.3 -j RETURN -p ARP --arp-ip-src 10.0.0.4 -j RETURN Bridge chain: I-vnet0-rarp, entries: 1, policy: DROP -p 0x8035 -s 54:0:0:0:0:1 -d Broadcast --arp-op Request_Reverse --arp-ip-src 0.0.0.0 --arp-ip-dst 0.0.0.0 --arp-mac-src 54:0:0:0:0:1 --arp-mac-dst 54:0:0:0:0:1 -j ACCEPT Bridge chain: O-vnet0-rarp, entries: 1, policy: DROP -p 0x8035 -d Broadcast --arp-op Request_Reverse --arp-ip-src 0.0.0.0 --arp-ip-dst 0.0.0.0 --arp-mac-src 54:0:0:0:0:1 --arp-mac-dst 54:0:0:0:0:1 -j ACCEPT -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
