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

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

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

ѽ҉ᶬḳ℠
Hi,

being in the process of migrating from dnsmasq I have been looking for an option in Kea to limit a particular subnet to static leases only, something similar to dnsmasq's > dhcp-range=static <, but after having perused the Kea admin documentation could not trace such?

Static leases might seem counterintuitive to DHCP but for security reasons some subnets are to be limited to static reservations only and not provide dynamic leases at all.

Thanks for pointing me in the right direction.

_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

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

Tomek Mrugalski
On 14.02.2019 09:14, ѽ҉ᶬḳ℠ wrote:
> being in the process of migrating from dnsmasq I have been looking for
> an option in Kea to limit a particular subnet to static leases only,
> something similar to dnsmasq's > dhcp-range=static <, but after having
> perused the Kea admin documentation could not trace such?
So you want a subnet without any dynamic allocation, just serve the
clients that have reservations?

Simply don't define dynamic pools. That should do the trick.

Tomek
_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

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

ѽ҉ᶬḳ℠

On 14/02/2019 11:45, Tomek Mrugalski wrote:
On 14.02.2019 09:14, ѽ҉ᶬḳ℠ wrote:
being in the process of migrating from dnsmasq I have been looking for
an option in Kea to limit a particular subnet to static leases only,
something similar to dnsmasq's > dhcp-range=static <, but after having
perused the Kea admin documentation could not trace such?
So you want a subnet without any dynamic allocation, just serve the
clients that have reservations?

Simply don't define dynamic pools. That should do the trick.

Tomek


Thank you for the input. The (simple) logic escaped me from perusing the documentation.

Though perhaps a bit off topic, please bear with me, I have been wondering about DUID in ipv4 since thought that it would be only applicable to ipv6?
To my understanding the DUID would be provided by the dhcp client but I have not found way to figure the clients's ipv4 DUID, all linux distros, in order to use it for host reservation. Neither iproute2 nor ifupdown2 seem to provide that information. Is there a way to harvest those ipv4 DUID?


_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

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

Francis Dupont
In reply to this post by ѽ҉ᶬḳ℠
My immediate idea is to simply not define a pool for such subnets?

Regards

Francis Dupont <[hidden email]>
_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

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

Tomek Mrugalski
In reply to this post by ѽ҉ᶬḳ℠
On 14.02.2019 12:20, ѽ҉ᶬḳ℠ wrote:
> Though perhaps a bit off topic, please bear with me, I have been
> wondering about DUID in ipv4 since thought that it would be only
> applicable to ipv6?
That was the original idea. But then the reality kicked in. The primary
use case for DUIDs in ipv4 is to be able to match requests coming from
dual-stack devices.

> To my understanding the DUID would be provided by the dhcp client but I
> have not found way to figure the clients's ipv4 DUID, all linux distros,
> in order to use it for host reservation. Neither iproute2 nor ifupdown2
> seem to provide that information. Is there a way to harvest those ipv4 DUID?
Not sure. If the client supports it, as a last resort you can capture
the traffic and extract its client-id option. That's not exactly a
convenient way, I admit that. I found a discussion about it on systemd
github: https://github.com/systemd/systemd/issues/394. It mentions some
pull requests that apparently were merged. You may want to look around
that area and see if anything comes up.

Tomek
_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

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

ѽ҉ᶬḳ℠

Kai Meitzner
On 14/02/2019 14:35, Tomek Mrugalski wrote:
On 14.02.2019 12:20, ѽ҉ᶬḳ℠ wrote:
Though perhaps a bit off topic, please bear with me, I have been
wondering about DUID in ipv4 since thought that it would be only
applicable to ipv6?
That was the original idea. But then the reality kicked in. The primary
use case for DUIDs in ipv4 is to be able to match requests coming from
dual-stack devices.

To my understanding the DUID would be provided by the dhcp client but I
have not found way to figure the clients's ipv4 DUID, all linux distros,
in order to use it for host reservation. Neither iproute2 nor ifupdown2
seem to provide that information. Is there a way to harvest those ipv4 DUID?
Not sure. If the client supports it, as a last resort you can capture
the traffic and extract its client-id option. That's not exactly a
convenient way, I admit that. I found a discussion about it on systemd
github: https://github.com/systemd/systemd/issues/394. It mentions some
pull requests that apparently were merged. You may want to look around
that area and see if anything comes up.

Tomek


The current dnsmasq ipv4 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?
Suppose such client identifier would be matching client-id in the Kea conf?

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.

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 reservation matching. My network management preference though is ifupdown2.

_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

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

Jason Guy
Keep in mind ifupdown2 is just a front-end for configuring the networking. The actual DHCP client is dhclient. There is certainly a dhclient.conf you can change, but do you want to do that on all clients? I just use the mac address for linux machines, and client-id is the default for windows (as I recall). I have not yet successfully made DHCPv6 relay return a static host reservation, so I have not tested DUID with IPv6. My advice is use the mac address and keep it simple. Seems unlikely to have MAC spoofing without many other layer2 issues occurring. Just my opinion.

Cheers,
Jason

On Thu, Feb 14, 2019 at 9:37 AM ѽ҉ᶬḳ℠ <[hidden email]> wrote:

Kai Meitzner
On 14/02/2019 14:35, Tomek Mrugalski wrote:
On 14.02.2019 12:20, ѽ҉ᶬḳ℠ wrote:
Though perhaps a bit off topic, please bear with me, I have been
wondering about DUID in ipv4 since thought that it would be only
applicable to ipv6?
That was the original idea. But then the reality kicked in. The primary
use case for DUIDs in ipv4 is to be able to match requests coming from
dual-stack devices.

To my understanding the DUID would be provided by the dhcp client but I
have not found way to figure the clients's ipv4 DUID, all linux distros,
in order to use it for host reservation. Neither iproute2 nor ifupdown2
seem to provide that information. Is there a way to harvest those ipv4 DUID?
Not sure. If the client supports it, as a last resort you can capture
the traffic and extract its client-id option. That's not exactly a
convenient way, I admit that. I found a discussion about it on systemd
github: https://github.com/systemd/systemd/issues/394. It mentions some
pull requests that apparently were merged. You may want to look around
that area and see if anything comes up.

Tomek


The current dnsmasq ipv4 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?
Suppose such client identifier would be matching client-id in the Kea conf?

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.

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 reservation matching. My network management preference though is ifupdown2.
_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users

_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

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

Tomek Mrugalski
In reply to this post by ѽ҉ᶬḳ℠
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
_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

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

ѽ҉ᶬḳ℠
In reply to this post by Tomek Mrugalski

On 14/02/2019 11:45, Tomek Mrugalski wrote:
On 14.02.2019 09:14, ѽ҉ᶬḳ℠ wrote:
being in the process of migrating from dnsmasq I have been looking for
an option in Kea to limit a particular subnet to static leases only,
something similar to dnsmasq's > dhcp-range=static <, but after having
perused the Kea admin documentation could not trace such?
So you want a subnet without any dynamic allocation, just serve the
clients that have reservations?

Simply don't define dynamic pools. That should do the trick.

Tomek


I tried this various ways but none seems to be working.

kea-dhcp4-server is running and listening either globally or on specified faces. According to the kea log there are no dhcp requests from clients on the subnet specified in the kea conf

"subnet4": [
        {
            "subnet": "172.24.0.0/16",
            "reservations": [
                {
                    "hw-address": "00:16:3e:88:e8:4e",
                    "ip-address": "172.24.41.10"
                }
            ]
        },

However, the log is showing dhcp requests from clients in other subnets that are not in the kea conf and that logically cannot be satisfied by kea:

ERROR [kea-dhcp4.bad-packets/12145] DHCP4_PACKET_NAK_0001 [hwtype=1 00:16:3e:fc:25:3f], cid=[ff:e0:55:d8:0c:00:02:00:00:ab:11:56:45:59:1d:16:60:db:75], tid=0xac615c91: failed to select a subnet for incoming packet, src 172.25.120.76, type DHCPREQUEST

As soon as specifying the other subnets in the kea conf however no dhcp requests are logged either for those subnets.

With dnsmasq running instead of kea, dnsmasq is of course stopped when running kea, there is no such issue and the clients are being assigned their static addresses as specified in the dnsmsaq conf.

So either I am missing something here or this being rather some sort of bug in kea. Either way I did not imagine that a transition from dnsmasq to kea would bear such complications and I am rather inclined to throw in the towel and stay with dnsmasq instead.


_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

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

ѽ҉ᶬḳ℠

On 18/02/2019 16:16, ѽ҉ᶬḳ℠ wrote:

On 14/02/2019 11:45, Tomek Mrugalski wrote:
On 14.02.2019 09:14, ѽ҉ᶬḳ℠ wrote:
being in the process of migrating from dnsmasq I have been looking for
an option in Kea to limit a particular subnet to static leases only,
something similar to dnsmasq's > dhcp-range=static <, but after having
perused the Kea admin documentation could not trace such?
So you want a subnet without any dynamic allocation, just serve the
clients that have reservations?

Simply don't define dynamic pools. That should do the trick.

Tomek


I tried this various ways but none seems to be working.

kea-dhcp4-server is running and listening either globally or on specified faces. According to the kea log there are no dhcp requests from clients on the subnet specified in the kea conf

"subnet4": [
        {
            "subnet": "172.24.0.0/16",
            "reservations": [
                {
                    "hw-address": "00:16:3e:88:e8:4e",
                    "ip-address": "172.24.41.10"
                }
            ]
        },

However, the log is showing dhcp requests from clients in other subnets that are not in the kea conf and that logically cannot be satisfied by kea:

ERROR [kea-dhcp4.bad-packets/12145] DHCP4_PACKET_NAK_0001 [hwtype=1 00:16:3e:fc:25:3f], cid=[ff:e0:55:d8:0c:00:02:00:00:ab:11:56:45:59:1d:16:60:db:75], tid=0xac615c91: failed to select a subnet for incoming packet, src 172.25.120.76, type DHCPREQUEST

As soon as specifying the other subnets in the kea conf however no dhcp requests are logged either for those subnets.

With dnsmasq running instead of kea, dnsmasq is of course stopped when running kea, there is no such issue and the clients are being assigned their static addresses as specified in the dnsmsaq conf.

So either I am missing something here or this being rather some sort of bug in kea. Either way I did not imagine that a transition from dnsmasq to kea would bear such complications and I am rather inclined to throw in the towel and stay with dnsmasq instead.

It seems that kea is not ready for prime time yet and I am calling it a day with kea for now.

All clients are lxc-containers and none is getting an address from kea, whether dynamic or static, whilst there is no such issue with dnsmasq. As mentioned previously kea is not even registering a dhcp request from those clients.

With kea listening globally the log is showing:

[kea-dhcp4.dhcpsrv/28994] DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface vethDU6QB4 is down or has no usable IPv4 addresses configured

dnsmasq has no such issue with bridge/veth interfaces.

_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users