<div> The firewall idea is interesting, but all of our DHCP is via relay and I don’t think I can capture the source MAC address from the relay. </div><div dir="auto"><br></div><div dir="auto"> We have 35,000 hosts DHCP-ing, to whitelist all but 100 sounds very inefficient. Further, in this case, we are only able to enumerate badness, new devices that behave properly should not be limited. </div><div dir="auto"><br></div><div dir="auto">There has to be a way to give kea a list of MAC addresses to ignore. </div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 22, 2019 at 8:03 AM Francis Dupont <<a href="mailto:fdupont@isc.org">fdupont@isc.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Munroe Sollog writes:<br>
> Perhaps random wasn't a good choice of words.  Given a MAC address we need<br>
> a way of ensuring it does not DHCP.  I'm open to alternatives to the<br>
> ignore/deny booting function.  Some sort of client classification?<br>
<br>
=> the simplest (and most efficient as a rogue client can for instance<br>
flood the server with junk queries) is to use a firewall feature to<br>
drop messages on the floor. At the Kea server level the standard way<br>
is to create a client class which matches all other clients and<br>
to guard subnets or pools with this class so not resource will be<br>
available to it. You can also write a hook to filter out messages<br>
but it requires to write some code (vs a config update).<br>
<br>
Regards<br>
<br>
Francis Dupont <<a href="mailto:fdupont@isc.org" target="_blank">fdupont@isc.org</a>><br>
<br>
PS: I cited the hook because it is the standard way to plug an<br>
authentication/authorization service to Kea.<br>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Munroe Sollog<div>Senior Network Engineer</div><div><a href="mailto:munroe@lehigh.edu" target="_blank">munroe@lehigh.edu</a></div></div></div>