[Kea-users] 1.4 - limit subnet to static reservations/leases

[Tomek Mrugalski]

On 14.02.2019 15:37, ѽ҉ᶬḳ℠ wrote:
> The current dnsmasq ipv/4/ leases (still in place) supposedly showing
> client identifier, e.g.
> ff:a9:13:fb:9b:00:02:00:00:ab:11:f0:18:bd:02:af:a5:19:a1.
> Perusing online resources has not cleared up for me whether there is a
> correlation between DUID and client identifier, some sources hinting the
> client identifier containing the DUID?
Client-id MAY contain DUID. Clients (presumably dual stack) that support
this optional extension may use DUID with some extra information as
client-id. See RFC4361 for details, especially section 6.1. In principle
Kea supports that, but I think it was never thoroughly tested.

> Suppose such client identifier would be matching */client-id/* in the
> Kea conf?
Kea can be told to match client-id (the whole option) or duid (a subset
of the client-id option), depending on your configuration. See
host-reservation-identifiers and some examples of host reservations.

> Since client-id spoofing would appear more difficult than mac spoofing I
> would probably prefer client-id. Just have to check whether client-ids
> are indeed ephemeral.
Depends on what you're using to spoof it. It's a configuration option in
dhclient.

> Seems a bit a of cumbersome way to run first a dhcp server to gather
> client-id/DUID from its linux clients to utilise such for host
This complaint that is over 15 years old now. If you're really
interested in the bottom of this, here's a bit of DHCP history. The
concept of DUID was created back in around 2000. The problem people
working on a spec that eventually became RFC3315 wanted to solve was a
failure of NIC cards. In the 90s network cards were failing sometimes
and when replaced, the host appeared as completely new device. So they
thought a new type of identifier is needed that would survive changing a
MAC address. DUID can do that. And it's about the only thing is does
great...

Now, fast forward to more recent times when network card failures is a
rare event. On the other hand, we have VMs being cloned (with the same
DUID appearing on two clones), we have dual boot devices (which each OS
using different DUID) and then there are PXE devices that may use
different DUIDs for each stage. Even in the simplest of cases - a laptop
being booted for the first time - a vendor can't print DUID on the box
the same way they print MACs, simply because the DUID is usually created
on the first boot.

What's more there are currently 4 different types of DUID defined and in
actual use: LLT (MAC address + timestamp of first boot of the device),
LL (just MAC address + some fixed, well known duid type), EN (vendor
assigned) and UUID. RFC3315 preferred LLT. When IETF was updating DHCPv6
spec, we tried to alleviate the problem and RFC8415 no longer says that
LLT is the default choice, but there's no easy solution after 15 years
of implementations.

Personally, I would say the concept of DUID didn't withstand the trial
of time well.

> reservation matching. My network management preference though is ifupdown2.
As Jason has suggested, please consider simply using MAC addresses. You
can tweak Kea DHCPv6 to look at MAC addresses. I admit that those are
not directly available in DHCPv6, but there are several modes of
extracting them from incoming packet. This has been implemented many
years ago and I don't remember anyone complaining about that. For
details, see

https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#mac-in-dhcpv6

Another aspect you may possible look at to let you make a better DUID vs
MAC decision is a mechanism defined in RFC6939. It makes client's MAC
addresses available to the DHCPv6 server. It requires relay to support
it, but that's easier to do than upgrading your clients.

Hope that helps,
Tomek