Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2023-06-19T11:01:38Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/72Radius option definitions2023-06-19T11:01:38ZGhost UserRadius option definitionsThe RadiusDesign calls for an optional mechanism that will query the Radius server about specific client. Typically this functionality has been done by a relay, which then inserted Radius options into DHCP message before forwarding it to...The RadiusDesign calls for an optional mechanism that will query the Radius server about specific client. Typically this functionality has been done by a relay, which then inserted Radius options into DHCP message before forwarding it to the server.
Kea should be able to understand such options. See RFC4014 (v4) and RFC7037 (v6) for details. Kea should be able to represent radius attributes as sub-options, so general mechanisms, like client classification could be used.
This ticket calls for option definitions only. No special handling logic should be implemented.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/414Use new lease user contexts in RADIUS accounting2024-03-21T16:21:16ZFrancis DupontUse new lease user contexts in RADIUS accountingMigrated from https://oldkea.isc.org/ticket/5658
Current code has many potential problems and was scheduled to use use contexts from the beginning but it was postponed because user contexts in leases were implemented later:
- save/load...Migrated from https://oldkea.isc.org/ticket/5658
Current code has many potential problems and was scheduled to use use contexts from the beginning but it was postponed because user contexts in leases were implemented later:
- save/load to a CSV file is implemented but never tested.
- eraseCreateTimestamp() is called only when a STOP event is sent so the timestamp stays in memory without more control
+ obviously using an user-context is the right way: extent following the lease one, save in stable storage, etc.
If memory leak on RADIUS accounting experiments are not conclusive this should be tried.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/435A design for "backends in hooks"2022-04-21T10:39:03ZTomek MrugalskiA design for "backends in hooks"We had a discussion about Kea packaging in 1.6 (see meeting notes 2019-01-24). The conclusion was that we want to prepare for Kea packaging better. In particular, the database backends should be moved to hooks that are loaded dynamically...We had a discussion about Kea packaging in 1.6 (see meeting notes 2019-01-24). The conclusion was that we want to prepare for Kea packaging better. In particular, the database backends should be moved to hooks that are loaded dynamically, rather than included during compilation time.
The overall intention is to have a directory where hooks could be loaded from. This is similar to Apache modules. They have 2 directories: mods-available and mods-enabled. The first one contains a list of modules (hooks). The second one has symlinks to those modules (hooks) that will be loaded. This approach is super easy to understand and use. Also, very extensible, because you can package backends and other hooks in independent RPM or DEB packages.
It's different than what we do now and several things have to be changed before we get there:
1. When Kea parses configuration, it has to know what lease-database and hosts-database backends are supported. Right now it's hardcoded* (but see below). We'd need to load the hooks first and they would register available backends, then we'd process rest of the configuration.
1. RADIUS is implemented as a hook and it does provide hosts backend. Before doing anything, please investigate how it registers "radius" hosts-backend type. This is not exactly a ready to use solution (because you can't configure "radius" backend in the config yet), but they underlying implementation of backend type registration is good.
1. we need to develop a code that would load all the hooks from a directory
Things to consider:
1. name the directory properly (people complained that the hooks have incorrect name libdhcp- and also are placed in incorrect directory)
2. perhaps we could have hooks that are loaded always (call them permanent hooks maybe?). Those would be put in the hooks-enabled directory and would be loaded at kea startup and not unloaded during reconfiguration? This would be most useful for parameter-less hooks (such a config backends)
3. apache allows having a separate config file for each module. IMHO this is a bit too much, but maybe it's something to look at after all?
The goal of this ticket is to write a design. It should conclude with w written design and a list of tickets needed to implement it.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1446Control the amount of certain attributes in RADIUS packets per RFCs 2865, 28662024-03-20T11:22:24ZAndrei Pavelandrei@isc.orgControl the amount of certain attributes in RADIUS packets per RFCs 2865, 2866Attributes that are marked with `0`, `0-1`, `1` in RFCs 2865, 2866 need to be verified when building a RADIUS packet. `0+` has no restrictions. More details in #1441.Attributes that are marked with `0`, `0-1`, `1` in RFCs 2865, 2866 need to be verified when building a RADIUS packet. `0+` has no restrictions. More details in #1441.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2032RADIUS hook support for expressions in accounting messages2023-10-30T21:17:57ZVicky Riskvicky@isc.orgRADIUS hook support for expressions in accounting messagesThe ARM states that expressions are supported in RADIUS, but apparently they are not supported in accounting messages. Can we add this into the accounting messages?
A user who purchased this hook on-line ran across this limitation.The ARM states that expressions are supported in RADIUS, but apparently they are not supported in accounting messages. Can we add this into the accounting messages?
A user who purchased this hook on-line ran across this limitation.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2358Subnet reselection by address and class in RADIUS2024-03-21T17:04:41ZAndrei Pavelandrei@isc.orgSubnet reselection by address and class in RADIUSPresume client C has Framed-Pool P and Framed-IP-Address A in RADIUS. Reselect is enabled in Kea.
Supposition of expected behavior:
1. Kea looks for a subnet that matches both criteria, that is: address A is in the subnet's range, and ...Presume client C has Framed-Pool P and Framed-IP-Address A in RADIUS. Reselect is enabled in Kea.
Supposition of expected behavior:
1. Kea looks for a subnet that matches both criteria, that is: address A is in the subnet's range, and the subnet has a pool classified with class P.
1. If subnet not found, Kea reselects to `SUBNET_ID_UNUSED`.
Current behavior:
1. Kea looks for a subnet that has a pool classified with class P. If found, Kea settles for it and does not continue the reselection process, even though it may violate the reservation through Framed-IP-Address.
1. If subnet not found, Kea looks for a subnet that has address A in its range. If found, Kea settles for it, even though it may violate the reservation through Framed-Pool.
1. If subnet not found, Kea reselects to `SUBNET_ID_UNUSED`.
In other words, there is an OR relation between the two attributes, when, in fact, there should be an AND because both things happen in the lease allocation process: the reserved address is leased and the class is assigned to the client. In further words, Framed-Pool has priority over Framed-IP-Address in reselection, even though this is not documented, but there probably should not be any priority if the supposition above is correct.
Edge case that violates the current behavior mentioned above even if it is considered correct:
1. Kea looks for a subnet that has a pool classified with class P. Kea finds subnet S and it happens to be the same subnet assigned to the client as part of the initial subnet selection process. Kea considers this as not a reselection since the subnet ID technically did not change, and thus continues the process of reselecting, believing it has not found the right subnet yet.
1. Kea looks for a subnet that has address A in its range. It finds one and is a different subnet than S. It selects that subnet, even though the first one would have been selected were it not for the unfortunate circumstance of having the subnet already selected to S before making the RADIUS auth call.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2360RADIUS subnet reselection does not apply subnet guards2023-05-30T11:02:05ZFrancis DupontRADIUS subnet reselection does not apply subnet guardsThe reselecSubnet* methods ignore subnet guards (i.e. subnet client class entries). It is not a critical problem because in configs for the RADIUS hook usually only pool guards are used.The reselecSubnet* methods ignore subnet guards (i.e. subnet client class entries). It is not a critical problem because in configs for the RADIUS hook usually only pool guards are used.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2761Out-of-subnet address reservations done via RADIUS authorization now reselect...2024-03-25T15:05:37ZAndrei Pavelandrei@isc.orgOut-of-subnet address reservations done via RADIUS authorization now reselect subnet despite reselect-subnet-address being false if the client got assigned to a shared-network subnetPrior to the merging of gitlab ticket 2631 in Kea 2.3.5, RADIUS reservations were allowed to be out-of-subnet. Arguably, this might not have been useful, but a nuissance instead. So from that perspective, the behavior might have been imp...Prior to the merging of gitlab ticket 2631 in Kea 2.3.5, RADIUS reservations were allowed to be out-of-subnet. Arguably, this might not have been useful, but a nuissance instead. So from that perspective, the behavior might have been improved. However, the logic is quite fragmented now:
| RADIUS reserved address | subnet type | reselect-subnet-address | Outcome before 2631 | Outcome after 2631 |
| ----------------------- | -------------- | ----------------------- | ------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------- |
| inside selected subnet | doesn't matter | doesn't matter | reservation leased, no reselection, address in range of subnet | same |
| outside selected subnet | standalone | false | reservation leased, no reselection, address out of range of subnet | same |
| outside selected subnet | standalone | true | reservation leased, subnet reselection is attempted globally | same |
| outside selected subnet | shared network | false | reservation leased, no reselection, address out of range of subnet | reservation leased, subnet reselection is attempted, but only within shared network |
| outside selected subnet | shared network | true | reservation leased, subnet reselection is attempted globally | same (unlikely, but it might be that the reselection is done only within the shared network, TBT...) |
Things that could be done:
* Document this behavior in the RADIUS ARM.
* Write unit tests to assert this new behavior.
* Adapt the system tests that started failing.
* `dhcp.hooks.test_radius.test_radius[v4-radius-reservation-outside-pool-multiple-subnets-memfile]`
* `dhcp.hooks.test_radius.test_radius[v4-radius-reservation-outside-pool-multiple-subnets-mysql]`
* `dhcp.hooks.test_radius.test_radius[v4-radius-reservation-outside-pool-multiple-subnets-postgresql]`
* `dhcp.hooks.test_radius.test_radius[v4-radius-reservation-outside-pool-network-memfile]`
* `dhcp.hooks.test_radius.test_radius[v4-radius-reservation-outside-pool-network-mysql]`
* `dhcp.hooks.test_radius.test_radius[v4-radius-reservation-outside-pool-network-postgresql]`next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2787A client class reservation in FreeRADIUS only applies to the first exchange i...2024-03-25T15:05:41ZAndrei Pavelandrei@isc.orgA client class reservation in FreeRADIUS only applies to the first exchange if there is also an address reservation for the same hostIf you have both an address reservation and a client class reservation in RADIUS, like so:
```
00:03:00:01:08:00:27:b0:c1:42 Cleartext-password := "08:00:27:b0:c1:42"
Framed-IP-Address = "192.168.52.52",
Framed-IPv6-Ad...If you have both an address reservation and a client class reservation in RADIUS, like so:
```
00:03:00:01:08:00:27:b0:c1:42 Cleartext-password := "08:00:27:b0:c1:42"
Framed-IP-Address = "192.168.52.52",
Framed-IPv6-Address = "2001:db8:50::52",
Framed-Pool = "gold",
Framed-IPv6-Pool = "gold"
```
The client class is only assigned to the packet from the first exchange, but not to the packet from the second exchange, like so:
```
DEBUG [kea-dhcp6.packets] DHCP6_QUERY_DATA duid=[00:03:00:01:08:00:27:b0:c1:42], tid=0xf9cf5f, packet details: localAddr=[ff02::1:2]:0 remoteAddr=[fe80::3442:f5d2:3c93:374c]:546
msgtype=1(SOLICIT), transid=0xf9cf5f
--
DEBUG [kea-dhcp6.dhcp6] DHCP6_CLASS_ASSIGNED duid=[00:03:00:01:08:00:27:b0:c1:42], tid=0xf9cf5f: client packet has been assigned to the following class(es): ALL, gold, KNOWN
--
DEBUG [kea-dhcp6.packets] DHCP6_RESPONSE_DATA responding with packet type 2 data is localAddr=[ff02::1:2]:547 remoteAddr=[fe80::3442:f5d2:3c93:374c]:546
msgtype=2(ADVERTISE), transid=0xf9cf5f
--
DEBUG [kea-dhcp6.packets] DHCP6_QUERY_DATA duid=[00:03:00:01:08:00:27:b0:c1:42], tid=0xf9cf5f, packet details: localAddr=[ff02::1:2]:0 remoteAddr=[fe80::3442:f5d2:3c93:374c]:546
msgtype=3(REQUEST), transid=0xf9cf5f
--
DEBUG [kea-dhcp6.dhcp6] DHCP6_CLASS_ASSIGNED duid=[00:03:00:01:08:00:27:b0:c1:42], tid=0xf9cf5f: client packet has been assigned to the following class(es): ALL, KNOWN
--
DEBUG [kea-dhcp6.packets] DHCP6_RESPONSE_DATA responding with packet type 7 data is localAddr=[ff02::1:2]:547 remoteAddr=[fe80::3442:f5d2:3c93:374c]:546
msgtype=7(REPLY), transid=0xf9cf5f
```
If the client class would have also been assigned in the second exchange, it could have potentially resulted in a different lease, depending on Kea configuration.
This behavior is exhibited with v4 too.
See https://gitlab.isc.org/isc-projects/kea/-/issues/2761#note_357250 for slightly more details.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2984Add support for Delegated-IPv6-Prefix to RADIUS hook2024-03-27T12:55:24ZDarren AnkneyAdd support for Delegated-IPv6-Prefix to RADIUS hookCurrently, the RADIUS hook can create a reservation for an IP address based on the content of framed-ipv6-address (https://www.rfc-editor.org/rfc/rfc6911#section-3.1) in the access-accept response. It would be nice to also be able to cr...Currently, the RADIUS hook can create a reservation for an IP address based on the content of framed-ipv6-address (https://www.rfc-editor.org/rfc/rfc6911#section-3.1) in the access-accept response. It would be nice to also be able to create a reservation for a prefix based on the content of delegated-ipv6-prefix (https://www.rfc-editor.org/rfc/rfc4818) in the access-accept response.
[RT22056](https://support.isc.org/Ticket/Display.html?id=22056)kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3103RADIUS realm config entry does nothing2023-11-09T15:41:47ZFrancis DupontRADIUS realm config entry does nothingFour possible solutions:
- to nothing (or put the ticket in Outstanding)
- add a note in ARM saying it is not yet supported
- remove it from the config
- implement it (i.e. adding @<realm> to all User-Name attributes)Four possible solutions:
- to nothing (or put the ticket in Outstanding)
- add a note in ARM saying it is not yet supported
- remove it from the config
- implement it (i.e. adding @<realm> to all User-Name attributes)next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3151Reject RADIUS config with multiple default NAS ports2023-11-23T14:42:38ZAndrei Pavelandrei@isc.orgReject RADIUS config with multiple default NAS portsA default NAS port applies to all packets. It makes no sense to have more than one default in a configuration, and that is likely an user error. It would be appropriate for the user to be notified, so that the config can be changed accor...A default NAS port applies to all packets. It makes no sense to have more than one default in a configuration, and that is likely an user error. It would be appropriate for the user to be notified, so that the config can be changed accordingly.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3226HA lease updates do not create an accounting entry in v62024-01-25T15:00:10ZAndrei Pavelandrei@isc.orgHA lease updates do not create an accounting entry in v6In v6, HA lease updates are done with the `lease6-bulk-apply` command which is not handled in the `command_processed` RADIUS callout.
This is unlike v4 which does create accounting entries for HA lease updates sent via `lease4-update`.In v6, HA lease updates are done with the `lease6-bulk-apply` command which is not handled in the `command_processed` RADIUS callout.
This is unlike v4 which does create accounting entries for HA lease updates sent via `lease4-update`.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3251Fix drop statistics in subnet6_select and RADIUS hook2024-03-07T14:55:13ZFrancis DupontFix drop statistics in subnet6_select and RADIUS hookThe pkt6-receive-drop is not correctly handled in the subnet6_select callout and the RADIUS hook adds another way to mess it.The pkt6-receive-drop is not correctly handled in the subnet6_select callout and the RADIUS hook adds another way to mess it.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3252HA multiple relationships and RADIUS reselect are incompatible2024-03-27T15:26:47ZFrancis DupontHA multiple relationships and RADIUS reselect are incompatibleNothing trivial can be done to fix this other to drop the first query (RADIUS hook parks the query at the subnet select callout and knows the right subnet when the RADIUS response is received). For other queries using cached RADIUS infor...Nothing trivial can be done to fix this other to drop the first query (RADIUS hook parks the query at the subnet select callout and knows the right subnet when the RADIUS response is received). For other queries using cached RADIUS information the correctness relies on the order of the HA and RADIUS hooks (RADIUS before HA).kea2.6.0https://gitlab.isc.org/isc-projects/kea/-/issues/3269Possible problem with RADIUS and shared networks2024-03-25T14:08:01ZFrancis DupontPossible problem with RADIUS and shared networksRADIUS uses the (re)selected subnet to fetch a cached host entry: this is not correct with shared networks where it should try all subnets of the shared networks without a guard incompatible with the query. And when RADIUS creates a new ...RADIUS uses the (re)selected subnet to fetch a cached host entry: this is not correct with shared networks where it should try all subnets of the shared networks without a guard incompatible with the query. And when RADIUS creates a new host entry for a reserved address it uses the (re)selected subnet instead of a subnet where the address belongs.
These two problems can make RADIUS to fail to find a cached entry: not a bug as the server will return the informations but not without performance impact...next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3299Improve MT RADIUS unit tests2024-03-26T18:31:40ZAndrei Pavelandrei@isc.orgImprove MT RADIUS unit testsImprove RADIUS unit tests:
- no goal: write tests for session history: instead implement #414
- MT: see below
- async access added new ways to have a query to be dropped: add these cases
- find a way to detect accounting exchange te...Improve RADIUS unit tests:
- no goal: write tests for session history: instead implement #414
- MT: see below
- async access added new ways to have a query to be dropped: add these cases
- find a way to detect accounting exchange termination (e.g. a class counter of pending exchanges)
RADIUS could have more thorough MT unit tests:
- Start thread pool for accounting by calling the `dhcp*_srv_configured` callout. Currently it is only called for auth. Waiting for work to finish in accounting is not as trivial for auth. Auth uses the unparking for that. (see last general point)
- In both access and accounting, start a second thread pool that simulates the core Kea thread pool / DHCP clients.
- Convert more (all?) ST unit tests to MT. Currently there are only 4 MT unit tests: (v4 + v6) x (access + accounting).kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3302Is Host Cache required for RADIUS?2024-03-28T16:15:48ZFrancis DupontIs Host Cache required for RADIUS?The Host Cache was designed for RADIUS in order to not perform an access/auth exchange with the RADIUS server for each query: when the query comes from an already seen client (same RADIUS idenfier) the answer from the RADIUS server is av...The Host Cache was designed for RADIUS in order to not perform an access/auth exchange with the RADIUS server for each query: when the query comes from an already seen client (same RADIUS idenfier) the answer from the RADIUS server is available from the host cache. This was critical when both were designed because the access/auth exchange was synchronous (i.e. blocking until the answer is received) and single threaded (i.e. blocking the whole DHCP service). Perhaps it is less true today but the host cache is in memory when RADIUS exchanges are over the network so far slower, and the Host Cache also handles negative answers so covers (excepting for the bug described in #3269) all cases.
The Host Cache has a second function for RADIUS: when the RADIUS server returns an address (vs a pool name which is translated into a client class name directly added to the query object) a host entry for this reserved address is inserted in the Host Cache. The idea is the host lookup will be able to find it. This is not essential: the host entry can be attached to the callout handle associated to the query and got back latter as the current code does for the [re]selected subnet.kea2.6.0