[kea-dev] Implementing Radius-based host reservation

Marcin Siodelski marcin at isc.org
Thu Aug 24 13:23:48 UTC 2017


Baptiste,

Support for Radius based reservations is definitely a useful feature and
we have discussed a need for this within the ISC engineering team
several times. We will certainly look at your request and will provide
some comments in your ticket. However, please allow the time for us to
gather together to discuss it. Currently, many of the team members are
still on vacation.

It is realistic that we'll get back to you by the end of next week.

Marcin Siodelski
ISC

PS. The delay in this response is also caused by the fact that it is a
holiday season.

On 16.08.2017 11:24, Baptiste Jonglez wrote:
> Sorry for the spam, I have just realised that there is a more appropriate
> kea-dev mailing list.
>
> We have just started the initial development of this feature. I have
> created a ticket to faciliate feedback from the Kea team:
> http://kea.isc.org/ticket/5349
>
> Thanks,
> Baptiste
>
> On 14-08-17, Baptiste Jonglez wrote:
> > I realise I may not have been clear: what we are looking for is *host
> > reservation* based on lookups towards a Radius server.
> >
> > So I was basically asking for a new hook point that would allow to
> perform
> > host reservation within a hook.
> >
> > A simpler alternative would be to implement radius support directly in
> > Kea, alongside the existing Mysql, Postgresql and Cassandra support for
> > host reservations.
> >
> > If we develop this (directly in Kea, not as a hook), would it have a
> > chance of being accepted?
> >
> > Thanks,
> > Baptiste
> >
> > On Mon, Aug 07, 2017 at 08:53:06AM +0200, Baptiste Jonglez wrote:
> >> Hi,
> >>
> >> We need Radius-based authentication based on the MAC address of the
> >> client.  That is, given the MAC address of a DHCPv4/v6 client, we
> want to
> >> hand out a pre-defined IPv4 address and IPv6 prefix.  If the client
> MAC is
> >> not registered in Radius, it should get no IP address.
> >>
> >> I started implementing this using the hooks system, but there is no
> >> practical hook point I can use.  I am currently using the
> "lease_select"
> >> hook point, basically doing this:
> >>
> >> - if the client MAC exists in radius, overwrite the IP address in the
> >>   existing lease passed by Kea to the callout;
> >> - if the client MAC is unknown, set status to NEXT_STEP_SKIP.
> >>
> >> The problem is that this happens *after* Kea has already selected a
> lease
> >> in the pool.  So, it first needs a pool in the Kea configuration file
> >> (which I don't need).  Also, for each client, Kea uses up one
> address of
> >> the pool even though I subsequently overwrite the address of the lease.
> >>
> >> For instance, the first client initially gets IPv4 address X.1, and I
> >> overwrite it with address X.189.  Then, the second client initially
> gets
> >> IPv4 address X.2, and I overwrite it with address X.77.  And so on: I'm
> >> not sure what happens when the pool is exhausted.
> >>
> >> Here is a log of address allocation showing what happens when the
> callout
> >> overwrites the IPv4 address of a lease:
> >>
> >> 2017-08-02 20:14:13.342 DEBUG [kea-dhcp4.alloc-engine/1941]
> ALLOC_ENGINE_V4_OFFER_NEW_LEASE allocation engine will try to offer
> new lease to the client [hwtype=1 96:ecf8:ac:d8:bd],
> cid=[ff:f8:ac:d8:bd:00:01:00:01:19:8e:03:b5:7c:dd:90:30:f4:2f],
> tid=0x62eebb95
> >> 2017-08-02 20:14:13.342 DEBUG [kea-dhcp4.hosts/1941]
> HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4 get one host with reservation for
> subnet id 1 and IPv4 address X.X.X.2
> >> 2017-08-02 20:14:13.342 DEBUG [kea-dhcp4.hosts/1941]
> HOSTS_CFG_GET_ALL_ADDRESS4 get all hosts with reservations for IPv4
> address X.X.X.2
> >> 2017-08-02 20:14:13.342 DEBUG [kea-dhcp4.hosts/1941]
> HOSTS_CFG_GET_ALL_ADDRESS4_COUNT using address X.X.X.2, found 0 host(s)
> >> 2017-08-02 20:14:13.342 DEBUG [kea-dhcp4.hosts/1941]
> HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4_NULL host not found using subnet
> id 1 and address X.X.X.2
> >> 2017-08-02 20:14:13.342 DEBUG [kea-dhcp4.dhcpsrv/1941]
> DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address X.X.X.2
> >> 2017-08-02 20:14:13.343 DEBUG [kea-dhcp4.callouts/1941]
> HOOKS_CALLOUTS_BEGIN begin all callouts for hook lease4_select
> >> lease4_select: starting.
> >> lease4_select: Client IP address: X.X.X.77
> >> 2017-08-02 20:14:13.343 DEBUG [kea-dhcp4.callouts/1941]
> HOOKS_CALLOUT_CALLED hooks library with index 1 has called a callout
> on hook lease4_select that has address 0x7fa3f9ce393 (callout
> duration: 0.081 ms)
> >> 2017-08-02 20:14:13.343 DEBUG [kea-dhcp4.callouts/1941]
> HOOKS_CALLOUTS_COMPLETE completed callouts for hook lease4_select
> (total callouts duration: 0.081 ms)
> >> 2017-08-02 20:14:13.343 DEBUG [kea-dhcp4.dhcpsrv/1941]
> DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address X.X.X.2
> >> 2017-08-02 20:14:13.343 INFO  [kea-dhcp4.leases/1941]
> DHCP4_LEASE_ADVERT [hwtype=1 96:ec:f8:ac:d8:bd],
> cid=[ff:f8:ac:d8:bd:00:01:00:01:19:8e:03:b5:7c:dd:90:30:f4:2f],
> tid=0x62eebb95: lease X.X.X.77 will be advertised
> >>
> >>
> >> Fundamentally, this use-case differs from the user_chk example:
> user_chk
> >> selects a subnet and lets Kea perform the lease allocation, while
> we want
> >> to perform the lease allocation ourselves in the callout.
> >>
> >> So, what about adding a hook point just before address allocation? 
> If the
> >> callout returns an address (or IPv6 prefix), check that there is no
> active
> >> lease that conflicts and just use it.  Otherwise, use the normal
> >> allocation strategy.
> >>
> >> Thanks and sorry for the long email,
> >> Baptiste
> >
> >
> >
> >> _______________________________________________
> >> Kea-users mailing list
> >> Kea-users at lists.isc.org
> >> https://lists.isc.org/mailman/listinfo/kea-users
> >
>
>
>
> > _______________________________________________
> > Kea-users mailing list
> > Kea-users at lists.isc.org
> > https://lists.isc.org/mailman/listinfo/kea-users
>
>
>
> _______________________________________________
> kea-dev mailing list
> kea-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-dev
>



More information about the kea-dev mailing list