... | ... | @@ -130,18 +130,13 @@ Handling of inbound LeaseQuery packets, would be provided by a new hook library, |
|
|
1. LeaseQuery::buffer<4/6>_receive() callout will set status to DROP, causing the
|
|
|
server to go on to the next DHCPX client packet.
|
|
|
|
|
|
### Access Control
|
|
|
Two points of access control have been suggested:
|
|
|
|
|
|
* Enabling LeaseQuery only for specific interfaces
|
|
|
|
|
|
Enabling LeaseQuery for specific interfaces could be done via a list interface names provided as a hook library parameter. Once the IP-address(es) in question are mapped to subnet, we would then check the subnet's interface against the configured list.
|
|
|
Note that the hook library will not have access to many of the server's internal functions, so some degree of code replication may be necessary. Consider it the cost of isolating the functionality within a hook.
|
|
|
|
|
|
However, using the new Kea core parameter proposed earlier provides some advantages. First it provides finer-grained scopes of control, potentially down to the pool level. It also keeps the scope's configuration together in single place which may be more maintainable for admins as well as avoiding the risk of enumerated lists (e.g. shared-network names, subnet ids) in hook parameters getting out-of-sync with the configured networks and subnets.
|
|
|
### Access Control
|
|
|
|
|
|
* Accepting LeaseQuery queries from a known list of IP addresses.
|
|
|
Access control will implemented as a list of known IP addresses.
|
|
|
|
|
|
This is aspect on access control is straight forward. We will limit LeaseQuery queries from a list of IP addresses. These would be part of the LeaseQuery hook library parameters.
|
|
|
This mechanism for access control is straight forward. We will only accept LeaseQuery queries from a list of IP addresses. These would be part of the LeaseQuery hook library parameters:
|
|
|
|
|
|
```
|
|
|
"library": "libdhcp_lq.so",
|
... | ... | @@ -177,5 +172,5 @@ Whether we implement this initially, or ever is another matter. It is suggested |
|
|
|
|
|
While the scope of this design does not include Bulk LeaseQuery, there is at least one point worth discussing. Bulk LeaseQuery, for both DHCPv4 and DHCPv6, provides for the ability to search for leases by relay attributes such as relay-id, remote-id, link address. In other words, by values within the same information that this design proposes be stored as part of a lease's user-context. The proposed format in this design is store these values opaquely rather than as individual sub-option values. While more efficient for lease storage IO during normal DHCP operations, it may not be the best arrangement for Bulk LeaseQuery performance and may well require walking lists of leases, as opposed to querying against indexes of explicit values.
|
|
|
|
|
|
|
|
|
We might find it necessary to split out the information into individual columns or for even tables/maps, in order to gain performance.
|
|
|
|