Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2024-03-21T14:50:56Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3275Kea DB allows to store too short identifier in the lease table2024-03-21T14:50:56ZSlawek FigielKea DB allows to store too short identifier in the lease tableWhile performing some experiments in Stork, I found that the Kea database accepts identifiers that are too short (less than 3 bytes) in the `lease6` table. It causes the error to be thrown when the identifier is processed. I noticed it b...While performing some experiments in Stork, I found that the Kea database accepts identifiers that are too short (less than 3 bytes) in the `lease6` table. It causes the error to be thrown when the identifier is processed. I noticed it blocks fetching this lease by API. I don't know if it has any other internal consequences.
Steps to reproduce:
1. Setup Kea 2.3.8 or above with PostgreSQL.
2. Configure lease database.
3. Insert a lease with too short DUID (e.g., `00`)
```
INSERT INTO lease6(address, duid, valid_lifetime, expire, subnet_id, pref_lifetime, lease_type, iaid, prefix_len, hwtype, hwaddr_source, state) VALUES('3001:db8:1::2', DECODE('00', 'hex'), 3600, NOW() + interval '1' MONTH, 1, 1800, 0, 1, 128, 0, 0, 1);
```
4. Send the `lease-get` command with the specified address (i.e., `3001:db8:1::2`).
5. Observe the error:
```
stork-agent-kea6-1 | INFO COMMAND_RECEIVED Received command 'lease6-get'
stork-agent-kea6-1 | INFO CTRL_AGENT_COMMAND_RECEIVED command lease6-get received from remote address 127.0.0.1
stork-agent-kea6-1 | INFO COMMAND_RECEIVED Received command 'lease6-get'
stork-agent-kea6-1 | ERROR LEASE_CMDS_GET6_FAILED lease6-get command failed (parameters: { "ip-address": "3001:db8:1::2", "type": "IA_NA" }, reason: Could not convert data to Lease6, reason: identifier is too short (1), at least 3 is required)
stork-agent-kea6-1 | ERROR HOOKS_CALLOUT_ERROR error returned by callout on hook $lease6_get registered by library with index 1 (callout address 0x7f12e8310e90) (callout duration 0.593 ms)
stork-agent-kea6-1 | INFO CTRL_AGENT_COMMAND_FORWARDED command lease6-get successfully forwarded to the service dhcp6 from remote address 127.0.0.1
```backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1541Add backend call counters2020-12-21T13:08:48ZFrancis DupontAdd backend call countersThe idea is to add simple counters (vs full stats) for backend API method calls. For instance in #1418 it would be very fine to confirm that a lease is not updated twice. I know that profiling can get the same information but this is far...The idea is to add simple counters (vs full stats) for backend API method calls. For instance in #1418 it would be very fine to confirm that a lease is not updated twice. I know that profiling can get the same information but this is far more immediate for a low cost (i.e. I am sure the cost will be more than recovered by optimizations it is expected to allow).
Note we do not need large counters: it does not matter if a counter wraps as soon as it takes a long time to happen...outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1463Performance improvement: lookup leases by address first when address is avail...2023-07-31T13:14:28ZAndrei Pavelandrei@isc.orgPerformance improvement: lookup leases by address first when address is availableEdit: TLDR: This issue is about looking up leases by address hint in renews and v6 requests. Currently, they are first searched by DUID/client ID. Because these are not primary keys, but indexes, this lookup is slower. Searching by addre...Edit: TLDR: This issue is about looking up leases by address hint in renews and v6 requests. Currently, they are first searched by DUID/client ID. Because these are not primary keys, but indexes, this lookup is slower. Searching by address which is a primary key should be significantly faster. I imagine this as a few lines of code changed, although it is affecting the allocation engine. There are concerns that this might affect host reservations, RADIUS or other aspects. I expect that to come up in tests.
---
When designing database scehmas, it is desirable to look at access patterns in order to define keys or indexes or maybe entire table definitions. When looking at the DHCP protocol, we can easily figure out that the key that we most want to use in a lookup is the client's identifier which is usually the DUID or client ID. This is not the case for current Kea since address is clearly chosen as sole primary key across all backends for the lease databases. This is probably because it is chosen based on it's unique properties. A v6 client can have multiple addresses per DUID and maybe it's the same for v4 in same strange use cases. This could have been solved by storing addresses as a list in DUID/clientID-keyed tables at the cost of complexity. But that is not my proposal.
We can leverage the current table structure by looking up by address when possible. This is effectively the case when an address hint is provided. A well known case when this happens is during the renew process, but I think I remember reading from a RFC that it can be provided in other DHCP messages as well. But a well-behaved client should (RFC SHOULD?) always send the address in their RENEW (I think it's still called REQUEST for DHCPv4?) and RENEWs are 99% of the DHCP messages sent in networks with high uptime. So it is an optimization for RENEW.
Concerns:
* Security? Honoring DHCP clients requesting address directly might lead to address starvation?
* No, after lookup by address finds nothing, the usual DISCOVER & SOLICIT messages go through with looking up by DUID/clientID. And then it will find the lease that belonged to the malicious client. Even if it did, add that to the list of security issues. Clients spoofing their DUID/clientID doesn't do the same?
* Are we sure we aren't providing the address to the wrong client?
* Yes. We can check in-memory/in-server if the DUIDs/clientIDs match. Even though what harm can the right lease given to the wrong client do?
* Does this affect the ability to reserve addresses/prefixes, RADIUS, hooks or other use-cases?
* To be investigated. I don't know. Because firstly I don't understand why host reservations are looked up before leases. This optimization is less impactful if we still search by DUID/clientID in hosts first. I would move the address lookup in the lease database at the beginning of the packet processing. But then why not move the DUID/clientID lookup at the beginning as well? If the client has an active lease, doesn't it stop there?backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/997Remove commit and rollback methods from lease and host manager APIs.2022-11-02T15:10:18ZFrancis DupontRemove commit and rollback methods from lease and host manager APIs.They are unused so useless. Note they make sense only with transactions which span over more than one service method and such transactions (nor a way to manage them) do not exist.They are unused so useless. Note they make sense only with transactions which span over more than one service method and such transactions (nor a way to manage them) do not exist.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/445add support for mongo db2019-02-07T17:00:17ZGhost Useradd support for mongo db---
name: mongodb
about: add mongodb support to kea dhcp server
---
**Some initial questions**
- could not find this request anywhere in issues or on the web
- sure, there are other databases support; but that's not the point
**Is you...---
name: mongodb
about: add mongodb support to kea dhcp server
---
**Some initial questions**
- could not find this request anywhere in issues or on the web
- sure, there are other databases support; but that's not the point
**Is your feature request related to a problem? Please describe.**
- Reduction of the numbers of databases on the client's systems
**Describe the solution you'd like**
- allow kea administrators to configure mongodb in kea
**Describe alternatives you've considered**
- Not really.
**Additional context**
- No.
**Funding its development**
- Sure to some very small degree.
**Participating in development**
- design discussions and testing
**Contacting you**
- Private messages to my gitlab.isc.org registered email address are fine.outstandinghttps://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/349Restricting timestamps in Kea backends to max supported values2022-11-02T15:08:42ZMarcin SiodelskiRestricting timestamps in Kea backends to max supported valuesThe following chapter of the Kea User's Guide `Limitations Related to the use of SQL Databases` claims that we restricted timestamps to 32 bit value past the epoch. I don't see us restricting this anywhere. Maybe we should revise which d...The following chapter of the Kea User's Guide `Limitations Related to the use of SQL Databases` claims that we restricted timestamps to 32 bit value past the epoch. I don't see us restricting this anywhere. Maybe we should revise which databases have which limitation and explicitly report an error upon an attempt to add higher timestamps.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/46Please add circuit-ID to result of get lease-42022-11-02T15:08:42ZGhost UserPlease add circuit-ID to result of get lease-4We want to identify leases with circuit ID, how can we get the circuit ID with the lease4-get?
I want to search for a lease with the circuit ID with lease-get.
Vennlig hilsen / Best regards
Frode SætreWe want to identify leases with circuit ID, how can we get the circuit ID with the lease4-get?
I want to search for a lease with the circuit ID with lease-get.
Vennlig hilsen / Best regards
Frode Sætrebacklog