Opened 2 years ago

Last modified 2 years ago

#5349 new enhancement

Host reservation based on Radius

Reported by: bjonglez Owned by:
Priority: medium Milestone: Kea1.x
Component: host-reservations Version: git
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DHCP Feature Depending on Ticket:
Estimated Difficulty: 0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

We are a small ISP that needs host reservation (both DHCPv4 and DHCPv6-PD) based on data stored in a Radius server.

The goal of this ticket is to keep track of our progress and get feedback from the Kea team, so that our changes have a higher chance of being integrated in Kea.

Current specifications:

  • the interface is similar to other host reservation mechanisms, with the following limitations:
    • only out-of-pool reservations are supported
    • it is not possible to add/delete reservations from Kea
  • configuration is done in Kea (hostname/port of the server, secret), similarly to the SQL backends
  • only IP addresses and IP prefixes will be fetched from Radius (standard Radius attributes). It may be possible to add more attributes such as hostname and options, but it would be advisable to use standard Radius attributes for this.

Subtickets

Change History (4)

comment:1 Changed 2 years ago by bjonglez

We have currently selected http://radcli.github.io/radcli/ as Radius library:

comment:2 Changed 2 years ago by bjonglez

There is a design decision about the configuration interface. The simplest way would be to reuse the same interface as the current SQL backends, in "hosts-database" section:

  • "type": "radius"
  • "host": IP or hostname of the Radius server
  • "port": UDP port to use to reach the Radius server
  • "user": unused
  • "password": secret to authenticate against Radius server
  • "readonly": always true for Radius
  • "name": this is currently supposed to be a SQL database name. It could be used to configure a realm appended to the MAC addresses (so that usernames sent to the Radius server would look like "MAC_address@name": this allows the Radius server to distinguish between several classes of clients)

However it may be necessary to add additional configuration parameters:

  • query timeout (mostly for UDP)
  • number of retries upon query timeout (mostly for UDP)
  • UDP or TCP transport (I'm not sure about the level of support for TCP in Radius servers)
  • advanced settings, like source IP address to send queries from, or NAS-IP-Address attribute sometimes used for access control by Radius servers.

Ideally, we would extend the current configuration interface, by making the new parameters only applicable to Radius (according to the doc, this is already done for some parameters like "readonly" that only apply to mysql/postgresql)

comment:3 Changed 2 years ago by bjonglez

So far, we have implemented this functionality as a new class RadiusHostDataSource? deriving from BaseHostDataSource? (similarly to MySQL or PgSQL backends).

Contrary to the other database backends, we have decided *not* to implement a RadiusConnection? class deriving from DatabaseConnection?. The reason is that we only implement a host database (there is no RadiusLeaseMgr?, only RadiusHostDataSource?), so there's no need to factor common code and share the database connection. Also, radcli has less boilerplate code than the SQL backends.

I am interested in feedback for this, maybe you prefer having all backends implement a Connection class for consistency?

comment:4 Changed 2 years ago by tomek

  • Milestone changed from Kea-proposed to Kea1.x

There's no specific requirement to have Connection class. It was just convenient for other backends. But I presume that there's no real expectation to keep leases in Radius, right? So this will be primarily for reservations. On the other hand, there are people who are interested in using radius for accounting, so this may be another part of the code that would use Radius.

Anyway, we discussed this ticket on Kea call today (2017-10-05) and decided that we want to keep an eye on it, but it's not something we can do in 1.3 or 1.4, so moving to 1.x milestone.

Note: See TracTickets for help on using tickets.