[kea-dev] Implementing Radius-based host reservation

Mon Aug 28 16:40:26 UTC 2017

Hello,

Thanks for the update, I understand that this is not the right time.  We
are looking forward for your feedback, we will soon update the ticket with
our progress so far.

Baptiste

On 24-08-17, Marcin Siodelski wrote:
> 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
> >
> 
-------------- 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/20170828/4adc8d36/attachment.bin>