... | ... | @@ -4,7 +4,7 @@ Welcome to Kea 1.9.6, the seventh monthly release of the 1.9 development branch. |
|
|
|
|
|
This release adds new features, improves existing features, clarifies documentation, and fixes a few bugs. The most notable changes introduced in this version are:
|
|
|
|
|
|
**Experimental TLS support**. This release introduces support for Transport Layer Security (TLS) in Control Agent (CA). The CA can now be configured to accept incoming HTTPS connections. Three modes of operation are available. The first is plain HTTP with TLS completely disabled (this was the only mode available so far). The second mode is encryption, where the CA accepts TLS connections. This is the typical mode when securing a website, where clients and servers are not under the control of the same organization. The third mode (and the default when TLS support is enabled) is mutual authentication between connecting clients and the CA server. In this mode, clients are required to identify themselves using TLS certificates: the clients verify the server's certificate and the server verifies the client's. This work was done in #1661, #1662, #1663, #1664, #1726, #1748, and #1758.
|
|
|
**Experimental TLS support**. This release introduces support for Transport Layer Security (TLS) in the Control Agent (CA). The CA can now be configured to accept incoming HTTPS connections. Three modes of operation are available. The first is plain HTTP with TLS completely disabled (this was the only mode available previously). The second mode is encryption, where the CA accepts TLS connections. This is the typical mode when securing a website, where clients and servers are not under the control of the same organization. The third mode (and the default when TLS support is enabled) is mutual authentication between connecting clients and the CA server. In this mode, clients are required to identify themselves using TLS certificates: the clients verify the server's certificate and the server verifies the client's. This work was done in #1661, #1662, #1663, #1664, #1726, #1748, and #1758.
|
|
|
|
|
|
The TLS support is considered experimental and currently has a number of limitations:
|
|
|
|
... | ... | @@ -26,7 +26,7 @@ We do encourage people to test this and report their experience. We're particula |
|
|
|
|
|
**Multi-threaded HA work**. Kea 1.8 introduced multi-threaded support for DHCP packet processing, which offers substantial performance gains. Unfortunately, if used with HA, the current implementation makes the lease updates sequential, effectively eliminating the benefits of multi-threading. Mitigating this limitation requires substantial rework of how HA connections are established, and in this milestone we made substantial progress towards solving this bottleneck. The MT-HA design has been proposed and reviewed. #1315 Also, the first major element of the solution (a multi-threaded HTTP listener) has been reviewed and merged. #1748 The HA-MT solution is not yet functional, but the experiments and planning phase are complete and we have moved onto the implementation phase. This work will continue in the next releases.
|
|
|
|
|
|
**Test farm migration**. While this is not something users are normally concerned with, it's an aspect that took a substantial amount of our team's time. Our Jenkins test farm was running on ISC-hosted hardware that was aging and was not very powerful. We often struggled with test execution times and were limited in the number of systems we could test on. Our QA team has now set up a new Jenkins instance using Amazon Web Services (AWS). The Kea test environment is exceedingly complicated, with MySQL, PostgreSQL, and Cassandra backends; RADIUS, NETCONF, and DNS servers; multiple Kea instances running in a variety of stand-alone, HA, and load-balancing modes; and various API and traffic generators. We have migrated the great majority of our environment, and while the bulk of the migration is done, not everything is running smoothly yet on the new platform. As such, our testing of this release is more lightweight than usual. This does not mean that the release is broken or has lower quality than usual; it simply means that we were not able to confirm its stability. Use with caution! #1774, #1761, #1773, #1770, #1751, #1757, #1752
|
|
|
**Test farm migration**. While this is not something users are normally concerned with, this project took a substantial amount of our team's time. Our Jenkins test farm was running on ISC-hosted hardware that was aging and was not very powerful. We often struggled with test execution times and were limited in the number of systems we could test on. Our QA team has now set up a new Jenkins instance using Amazon Web Services (AWS). The Kea test environment is exceedingly complicated, with MySQL, PostgreSQL, and Cassandra backends; RADIUS, NETCONF, and DNS servers; multiple Kea instances running in a variety of stand-alone, HA, and load-balancing modes; and various API and traffic generators. We have migrated the great majority of our environment, and while the bulk of the migration is done, not everything is running smoothly yet on the new platform. As such, our testing of this release is more lightweight than usual. This does not mean that the release is broken or has lower quality than usual; it simply means that we were not able to confirm its stability. Use with caution! #1774, #1761, #1773, #1770, #1751, #1757, #1752
|
|
|
|
|
|
**Design for incremental lease updates**. The Stork project would like to be able to provide more insight into leases being assigned, but the current API is not well-prepared for it. It can enumerate all leases, but using existing calls periodically would incur a substantial burden on a Kea server. As such, a design for cached mode and incremental lease updates has been written. #1230
|
|
|
|
... | ... | |