[kea-dev] Implementing Radius-based host reservation

Wed Aug 16 09:24:53 UTC 2017

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/kea-dev/attachments/20170816/7d0af180/attachment.bin>