2023-11-02
Network firewalls and Ethernet addresses
Over on the Fediverse I mentioned that on some networks we authorize machines by controlling what Ethernet addresses ('MACs') get what IP addresses. In response, I was asked a very good question about why not have the firewall work by Ethernet address instead of IP. A starting answer is that firewalls have traditionally not had particular good support for working on MACs, and have instead focused on IPs. But why do firewalls prefer to work this way? There are probably several reasons, but I will theorize that a good part of it is that IP addresses are both more general and easier to work with.
First, IP addresses are more general, as they're preserved across router hops and the destination address is available much earlier even for destinations that are directly attached to the same network as the firewall. An Ethernet address is only useful if the sending or receiving machine is on the same network as the firewall and talking to it directly; otherwise it will be the MAC of some router. Or, to put it differently, the Ethernet addresses of packets are constantly being rewritten by everything that touches them (more or less) in the natural course of events, while IPs only change if someone does it deliberately. IPs tell you the (purported) endpoint, while MACs only tell you the immediate next or previous hop. Often the endpoints are much more meaningful to firewalls than the immediate hops.
(Partly this is a result of most network traffic being routed traffic. Of course, controlling the ability to get off a network is an exception.)
Second, IPs are generally easier for a firewall to work with because they're more structured. Ethernet addresses are not quite random, but from a firewall's perspective they usually might as well be; the list of MACs that are or could be on some network generally has no structure or organization to it, since the devices may come from many vendors with many assigned Ethernet prefixes. IP addresses are much more hierarchical (by design) and so in many situations are much more amenable to compact representations and data structures with good performance. Or to put it another way, there's no MAC equivalent of '192.168.1.0/24'.
(Often there will also be fewer active IPs than there are known and potentially active MACs, so even without structure to the IP addresses the firewall has fewer objects to care about.)
Since DHCP servers turn MACs into IPs, they have to deal with much the same challenges as firewalls. However, they have two advantages. The first is that they're in user space instead of in the kernel, which means they have a lot more options (and the consequences are lower). The second is that they have to do this mapping process only infrequently and they're not in the critical path for per-packet latency. If it takes half a second or a second or even ten seconds to get a DHCP lease, this is probably not critical; if it takes a tenth of a second for your packet to go through the firewall, this is very bad. A DHCP server can usually afford to do slow things where a firewall can't.
(Also, a linear array of MACs is not that space consuming, at least by the standards of user space programs. If you don't have any additional data, you can pack a table of 100,000 of them into just under 600 KiB. If the DHCP server keeps them in sorted order, matching a MAC can be done with binary search. Most DHCP servers probably don't have anywhere near 100,000 registered MACs.)