|
|
[[_TOC_]]
|
|
|
|
|
|
## GSoC 2018 students
|
|
|
Congratulations on identifying one of the core technologies critical to networking and the Internet! DHCP is how devices get addresses so they can participate in a network, and the most basic way of controlling and restricting access. Working on core infrastructure like this gives you an opportunity to have a significant impact.
|
|
|
|
|
|
1. We recommend that you first read the [Introduction to the Kea Users Guide](http://kea.isc.org/docs/kea-guide.html#intro).
|
|
|
2. Then, [download](https://www.isc.org/downloads/) and install Kea and see if you can get it running. If you have gotten this far, this is a very good sign!
|
|
|
3. Browse the archives to read some of the discussion on the [Kea-users@lists.isc.org](https://www.isc.org/kea-users-mailing-list/). This will give you an idea of how people are using Kea, and what problems or challenges they are facing. If you plan to proceed with a proposal, we recommend you join the list so you can also post questions.
|
|
|
4. Pick a project from the list below that sounds interesting to you. What is the essential objective: what would success look like? How would you propose to tackle the project? What do you think are the primary tasks? If you plan to complete the project in a summer, about how much time would you want to spend on each task or milestone? What are the main questions you have about how to proceed? ''This is the first draft of your proposal.
|
|
|
5. Send us that draft, and we will respond back with comments and advice, and probably ask you to provide more details. You are on your way to creating a good quality final proposal.
|
|
|
6. **Submit your proposal (.pdf) to GSOC between March 12 - 27th.**
|
|
|
|
|
|
## Ideas for Kea Community Projects
|
|
|
The ideas list below is intended to provide you with starter ideas for GSOC projects. Please feel free to propose something different, we are flexible. These are all things we would like to see in Kea, that the core team doesn't have time to work on. Some of these projects may be a little ambitious for a GSOC project - if you want to propose something that is a little easier or less ambitious, that is fine. It is better to downscope the project and complete it than attempt something unrealistic.
|
|
|
|
|
|
|
|
|
## Check the Kea project roadmap
|
|
|
|
|
|
Familiarize yourself with what's going on in the project, as Kea is a very lively project.
|
|
|
|
|
|
### 1. Kea Event Reporting
|
|
|
|
|
|
Kea has a RESTful API for various management activities and monitoring, like statistics, ability to inspect and manage configuration on various levels, including configuration and run-time elements. However, it does not provide any way to signal that certain events have occurred, like running out of addresses, an address detected to be duplicate or other faulty conditions.
|
|
|
|
|
|
**Why**: Modern networks get more and more complex. With increasing complexity it is important to be able to keep up the pace while not being overwhelmed with the amount of information. Being able to filter out the noise and pick only the essential information can take you a long way.
|
|
|
|
|
|
**Outcome**: Design and implement a mechanism for reporting events, then use that mechanism to augment existing Kea code to report several chosen events. If successful this would become part of the core Kea distribution.
|
|
|
|
|
|
**Skills required:** C++11 necessary, DHCP and REST API familiarity desired, some web interface design skills are nice to have
|
|
|
|
|
|
**Mentor:** Marcin Siodelski / Tomek Mrugalski
|
|
|
|
|
|
**Complexity:** medium (assuming you know C++ and know a thing or two about REST API) to insane (if you never heard about DHCP and think laptops and phones connect to networks by pure magic)
|
|
|
|
|
|
### 2. Statistics enhancements (2 candidates)
|
|
|
|
|
|
Kea is currently able to report dozens of statistics. However, for each statistic there is only one specific value being reported. For certain types of activities it is highly desirable to have multiple observations over time. Having many data points gives an insight into processes that are changing over time, e.g. daily patterns in user activities, DOS detection and mitigation etc.
|
|
|
|
|
|
**Why**: Sysadmins love to have deeper insight into what's going on in their networks. Some dangerous events can be predicted and prevented.
|
|
|
|
|
|
**Outcome**: Add some new types of statistics to Kea, such as time-series 'buckets'. This will likely require implementing additional functions to manage statistics, set thresholds, recalculate values, export all or a subset of values, etc.
|
|
|
|
|
|
**Skills required:** C++11 necessary, basic understanding of mathematical statistics would be useful.
|
|
|
|
|
|
**Mentor:** Tomek Mrugalski
|
|
|
|
|
|
**Difficulty**: easy, unless a bit of math scares you off
|
|
|
|
|
|
### 3. Kea Monitoring Dashboard (DONE in 2018 - see Kea-Anterius on Github!)
|
|
|
|
|
|
Kea software provides a REST API for remote management, but today we don't provide any management tools that implement and demonstrate the API. Such an application (most likely an interactive web app) would showcase the new features developed in goals !#1 and !#2 above. Such an application can either be developed from scratch or by integrating Kea (via the REST api) with an existing open source dashboard project. One nice example is the Glass project, which provides a management dashboard for ISC DHCP (see [Glass project homepage](https://github.com/Akkadius/glass-isc-dhcp)).
|
|
|
|
|
|
**Why**: Because going through tons of logs is difficult. Looking at shiny dashboard in your browser is much easier way to understanding what's going on in your network. A good dashboard that presents only the most important things will get you a long way.
|
|
|
|
|
|
**Outcome**: The result could be either a standalone web GUI dashboard for Kea, or a code blob submitted (likely to another open source project) implementing support for the Kea REST API.
|
|
|
|
|
|
**Skills required:** depends on the solution chosen (!JavaScript, PHP, Node.js or similar)
|
|
|
|
|
|
**Mentor:** Vicky Risk, Tomek Mrugalski
|
|
|
|
|
|
**Difficulty**: medium, assuming you have prior experience with REST API
|
|
|
|
|
|
### 4. HTTP GET Support
|
|
|
Kea supports many commands that are exposed via REST interface. Some of them are read-only in nature, like retrieving configuration (whole or parts of it, like whole configuration, specific subnet, specific host, specific address lease etc.) or statistics. Unfortunately, Kea uses POST mechanism to retrieve all of them. Some commands could be limited to GET mechanism. Many deployments that do not want to change Kea configuration on the fly could limit access to GET only rather than allowing POST access. This would have security benefits.
|
|
|
|
|
|
**Why**: Nice small security improvement in REST interface that will be applauded by users. Great way to learn internals of HTTP protocol.
|
|
|
|
|
|
**Outcome**: Ability to distinguish between read-only (safer) and read-write commands (more dangerous).
|
|
|
|
|
|
**Skills required:** C++11 necessary, boost, http protocol familiarity
|
|
|
|
|
|
**Mentor:** Marcin Siodelski (?)
|
|
|
|
|
|
**Difficulty**: easy/medium
|
|
|
|
|
|
### 5. **Multi-tenancy**
|
|
|
|
|
|
Typical DHCP server is expected to manage a certain number of subnets, with the expectation that each subnet is unique. However, in some deployments it may be desired to use overlapping address spaces, e.g. multiple home gateways each using the same template of privave addresses (RFC1918). This requires a thorough understanding of how DHCP operates.
|
|
|
|
|
|
**Why**: People saying "nah, can't be done?" always annoyed you? Prove them wrong.
|
|
|
|
|
|
**Outcome**: A server that can handle ovelapping subnets in different locations without getting confused about the which device belongs to which subnet. I'm not aware of any DHCP software that could pull that off. Doing something for the first time is fun, even if it's a bit risky.
|
|
|
|
|
|
**Skills required:** C++11, good understanding of DHCP, some database (MySQL, Postgres and/or Cassandra) experience is also needed.
|
|
|
|
|
|
**Mentor:** Tomek Mrugalski
|
|
|
|
|
|
**Difficulty**: hard
|
|
|
|
|
|
### 6. DDNS GSS-TSIG
|
|
|
|
|
|
Kea is a DHCP server that has the capability to generate DNS Updates. Those updates are protected with TSIG signatures. There is a mechanism that defines how to extend TSIG with GSS-API interface. For details, see [wikipedia page on GSS-TSIG](https://en.wikipedia.org/wiki/Generic_Security_Service_Algorithm_for_Secret_Key_Transaction). Also see [GSS-TSIG overview](https://docs.infoblox.com/display/NAG8/About+GSS-TSIG).
|
|
|
|
|
|
**Outcome**: Better flexibility regarding security protection of DNS zone
|
|
|
|
|
|
**Skills required:** C++, kerberos, general cryptography, dns, need to be able to read and understand IETF RFC documents
|
|
|
|
|
|
**Mentor:** Thomas Markwalder (?), Francis Dupont (?)
|
|
|
|
|
|
**Difficulty**: hard (medium if skilled with cryptography)
|
|
|
|
|
|
### 7. IPv6 Reconfiguration and Renumbering (DONE in 2018)
|
|
|
|
|
|
IPv6 is not just IPv4 with longer address space. There are many new and radically different mechanisms. One of them is IPv6 renumbering. The concept seems simple. You have some address space deployed in your network with devices getting addresses and prefixes from your DHCP server. For some reason (e.g. you are migrating to a different ISP) your network addressing scheme will change and you want to gradually migrate your network. There will be an overlap when both old and new addresses be in use. The goal of this project is to extend Kea DHCP server to be able to handle both addressing schemes at the same time and gradually migrate devices to the new one.
|
|
|
|
|
|
Being able to handle the reconfiguration process covers several aspects. First, there has to be a way to convey to clients that the addressing scheme and thus their configuration has changed (this will be handled with the ability to store multiple addresses or prefixes in IA_NA or IA_PD containers). Second, the server logic has to be extended to be aware of old configuration being retired and a new configuration being deployed (this will require some extensions to the server configuration). Third, the server should be able to trigger the clients to initiate their reconfiguration process (there is a Reconfigure mechanism with RKAP security protocol that protects it). All those mechanisms (except server configuration, which is implementation dependent and thus not part of the standard) are described in https://datatracker.ietf.org/doc/draft-ietf-dhc-rfc3315bis/.
|
|
|
|
|
|
**Why**: Because IPv6 is cool. A nice way to learn DHCPv6 and work with IETF protocols in general.
|
|
|
|
|
|
**Outcome**: Implement support for assigning multiple IPv6 addresses in a single IA_NA, to facilitate the graceful renumbering. The new lease is assigned while the old lease lifetime is being decreased during renewals and eventually expires.
|
|
|
|
|
|
**Skills required:** C++, DHCPv6 familiarity
|
|
|
|
|
|
**Mentor:** Tomek Mrugalski
|
|
|
|
|
|
**Difficulty**: medium
|
|
|
|
|
|
### 8. LDAP backend
|
|
|
|
|
|
One of the most attractive features of Kea is the option of storing all leases in a separate database backends. Kea currently supports both MySQL and PostgreSQL database backends and we are working on a project now to add Cassandra support. One of the best-loved features of ISC DHCP was the community-contributed LDAP backend. It would be great if we could have an equivalent LDAP backend for Kea.
|
|
|
|
|
|
**Why**: Understanding how to extend complex code (Kea is over 500kloc) with a new functionality without learning the whole codebase. Getting experience with LDAP.
|
|
|
|
|
|
**Outcome**: Kea being able to store host reservations in LDAP.
|
|
|
|
|
|
**Skills required:** C++, LDAP, DHCP familiarity is nice, but not necessary
|
|
|
|
|
|
**'Mentor:** Tomek Mrugalski
|
|
|
|
|
|
**Difficulty**: easy/medium
|
|
|
|
|
|
### 9. Performance benchmarks
|
|
|
|
|
|
Kea supports several database backends: memfile, MySQL, Postgres and Cassandra. We're in a process of accepting [a patch](https://github.com/isc-projects/kea/pull/36) for google benchmark. Once the code is merged, we should start measuring performance of each backend, tweak its parameters as necessary and improve its performance.
|
|
|
|
|
|
**Why**: Like tweaking things and seeing who would come first? Performance optimization is a valuable skill.
|
|
|
|
|
|
**Outcome**: A detailed white paper on Kea performance reporting on the testing methodology and results aimed at prospective implementers. This could compare Kea performance in different scenarios (e.g. with different backends), it could provide tips on how to improve performance (based on testing results), or it could compare performance of Kea to ISC DHCP. If successful, this paper could also be submitted as a conference presentation. Another outcome, also highly desirable, would be some automation that could be committed to Kea to reproduce the test results more automatically so that performance can be tracked in subsequent versions.
|
|
|
|
|
|
**Skills required:** familiarity with MySQL, Postgres and/or Cassandra, scripting, perhaps some C++ coding experience if you want to try some optimizations and developing new benchmarks.
|
|
|
|
|
|
**Mentor:** Vicky Risk, Tomek Mrugalski
|
|
|
|
|
|
**Difficulty**: trivial to hard (depending on your expertise and how deep you want to go)
|
|
|
|
|
|
### 10. **Leasequery support**
|
|
|
|
|
|
The mechanism defined in RFC4388 and RFC5007 provide a mechanism to query the server for specific leases. In simpler words you can query the server and check if an address is used and if it is, who is using it. This mechanism is typically used by relays that check whether specific client indeed has specific address. See #5510 for a nice example.
|
|
|
|
|
|
**Why**: Learning one of more advanced DHCP features. You will learn how protocols are defined, how to get the protocol standard from IETF, how to read and understand it and how to implement a new feature that is conformant to the specification.
|
|
|
|
|
|
**Outcome**: Extend Kea server with the leasequery capability.
|
|
|
|
|
|
**Skills required:** C++11 required, DHCPv4/DHCPv6 familiarity is desired, but not strictly required
|
|
|
|
|
|
**Mentor:** Tomek Mrugalski
|
|
|
|
|
|
**Difficulty**: easy
|
|
|
|
|
|
### 11. ISC DHCP => Kea Migration Assistant
|
|
|
This is a web site, or web page anyway, that will enable a user to upload an ISC DHCP configuration file. The file will then be fed through a modified version of ISC DHCP which will save the configuration file in a format that Kea can import. The process will also generate a log file, which will flag any errors or configuration statements in the original file that could not be translated to a Kea configuration. We have the modified version of ISC DHCP already more or less done, what we need is the infrastructure and UI to upload, process, and respond back to the user.
|
|
|
|
|
|
**Why**: To help a current user of ISC DHCP migrate to Kea, by generating an equivalent configuration for Kea from an existing ISC DHCP configuration.
|
|
|
To help a current user of ISC DHCP efficiently determine what features they are currently using are not supported by Kea.
|
|
|
To guide a current user of ISC DHCP in creating a usable Kea configuration for their existing deployment.
|
|
|
To predict how likelihood of success of a migration at this time.
|
|
|
To introduce DHCP administrators to Kea as a potential option
|
|
|
To introduce ISC DHCP support services
|
|
|
|
|
|
**Outcome**:
|
|
|
A web site or we page that will upload and parse an ISC DHCP configuration file, and emit a resulting Kea configuration file or files, and a log file with messages about what did not translate.
|
|
|
it might be even better if the log messages could quote from the configuration file, to make it easier to find the bits that did not translate
|
|
|
Must allow the user to download the resulting file(s), or email a link to a download file within <10 minutes.
|
|
|
Extra credit:
|
|
|
- provide some advice about interpreting the resulting log files
|
|
|
- provide links to documentation or better, some steps to migrate the current deployment, including migrating the active leases
|
|
|
|
|
|
**Skills required:** This is mostly a web front-end development job, but knowledge of DHCP is also very helpful.
|
|
|
|
|
|
**Mentor:** Tomek Mrugalski, Vicky Risk
|
|
|
|
|
|
**Difficulty**: easy
|
|
|
|
|
|
## Final Status
|
|
|
Two projects have been selected and completed. Here are the results:
|
|
|
|
|
|
### 3. Kea Monitoring Dashboard
|
|
|
Desciption of this project on GSoC web pages: https://summerofcode.withgoogle.com/archive/2018/projects/5093363330056192/
|
|
|
|
|
|
Results of this work can be found on GitHub: https://github.com/isc-projects/kea-anterius
|
|
|
|
|
|
### 7. IPv6 Reconfiguration and Renumbering
|
|
|
Desciption of this project on GSoC web pages: https://summerofcode.withgoogle.com/archive/2018/projects/6295758684815360/
|
|
|
|
|
|
Results of this work can be found here: https://gitlab.isc.org/isc-projects/kea/wikis/designs/reconfigure-design |