I've been wanting to implement a dynamic ARP filter (DHCP snooping + ARP filtering) for ages now, but arptables/ebtables just didn't cut it. Hopefully this will be easier/viable now. Because I still don't think ArpON sniffs DHCP leases for its mapping (it intercepts and replays ARP requests or something) and it doesn't filter rogue DHCP servers. I'm just amazed ARP spoofing/ARP cache poisoning is still a viable attack vector on home networks in 2014.

Please see the "master" branch of FreeRADIUS. https://github.com/FreeRADIUS/freeradius-server/

It can accept both DHCP and ARP protocols, and will decode them into attribute-value pairs. Those can then be referenced in a policy language, and stored to / read from a database.

I'm the author. :) It's no longer just a RADIUS server. I've been looking for a DHCP / ARP checker for a while, and couldn't find anything useful. Rather than writing something from scratch, I decided it was easier to just add ~2K LoC to FreeRADIUS. I could then leverage the policy language and database integration, so I didn't have to re-write all of that, either.

Excellent. :) I will look into this.

I am targeting embedded devices on OpenWRT, which means it needs to be as simple and small as possible, so I hope the code is tight.

But on the other hand, I would prefer to not reinvent the wheel.

The code is tiny. It already runs on OpenWRT, so there's no issue there.

You need to implement DHCP Snooping at Layer 2 for it to really work, and these days I think all major switch vendors support it. Unless you're building a Linux L2 switch I don't see why you would want to implement DHCP Snooping.

You need DHCP snooping for proper ARP reply filtering. It is the cleanest way of determining MAC address<->IP address mappings.

Note libnftables was just renamed to libnftnl http://www.marshut.com/imyzmp/libnftables-renamed-to-libnftn... A later, higher-level library will probably get the name libnftables.

> It adds a simple virtual machine to the kernel that is able to execute bytecode to inspect a network packet and make decisions on how that packet should be handled.

I wonder how long it's going to take until someone figures out a way to craft a specific sequence of packets that remotely do something nasty at the kernel level :P

It's not different than the rest of the network stack, most of it consists in "inspecting packets" in one way or another, and security bugs can be (and some times are) introduced.

But nftables is actually a big win from a security perspective, because it simplifies the current code (lots of duplicated code goes away) and moves other parts to userspace.

Old netfilter system: 70.000 LoC in kernel + 50.000 in userspace

nftables: 7.000 LoC in kernel + 50.000 in userspace

(source: http://www.slideshare.net/ennael/2013-kernel-recipesnftables)

Also note that it's not really a "virtual machine" comparable with java, this is how the developers actually describe it

    In a nutshell, nftables provides a pseudo-state machine with 4 general
    purpose registers of 128 bits and 1 specific purpose register to store
    verdicts. This pseudo-machine comes with an extensible instruction set,
    a.k.a. "expressions" in the nftables jargon. The expressions included
    in this patch provide the basic functionality, they are:
    
    * bitwise: to perform bitwise operations.
    * byteorder: to change from host/network endianess.
    * cmp: to compare data with the content of the registers.
    * counter: to enable counters on rules.
    * ct: to store conntrack keys into register.
    * exthdr: to match IPv6 extension headers.
    * immediate: to load data into registers.
    * limit: to limit matching based on packet rate.
    * log: to log packets.
    * meta: to match metainformation that usually comes with the skbuff.
    * nat: to perform Network Address Translation.
    * payload: to fetch data from the packet payload and store it into
      registers.
    * reject (IPv4 only): to explicitly close connection, eg. TCP RST.
    
    Using this instruction-set, the userspace utility 'nft' can transform
    the rules expressed in human-readable text representation (using a
    new syntax, inspired by tcpdump) to nftables bytecode.

I don't even think this is the first vm in the networking part of the kernel.

No, BPF is very old.