[kea-dev] Moving forward with secure-dhcp6

Tomek Mrugalski tomasz at isc.org
Wed Aug 12 14:10:24 UTC 2015


Folks,

As you may be aware, Francis did an excellent job with implementing
secure DHCPv6 prototype in Kea, as part of the IETF"93 hackathon
preparation. His code is now available on sedhcpv6a branch.

We need a plan to review this code and merge it to master eventually.
That code change is huge (almost 14k lines), so it's infeasible to do
the review in one step. If we delay this too much, the code will become
outdated and a lot of effort would be wasted. Here's what I propose:

Let's split the changes into several tickets:
1. Changes in lib/cryptolink and lib/util. There's a lot of code, but
it's mostly wrappers around various hash and other crypto methods.
2. Storage for dynamic host information (currently held in TSHost in
src/libdhcpsrv/tmp_state_host.h). This part will involve a proper
design phase, with the usual kea-dev discussion.
3. Configuration parsers for secure details (keys, certs)
4. Use of all that infomation in src/bin/dhcp6.
5. Documentation update

#1 should be very easy. The most tricky part is #2, so I'd like to talk
about this for a bit. The problem here is as follows. We currently have
a HostMgr, which manages a collection of Host objects. It's a bit more
involved, as HostMgr is just a dummy interface for HostDataSource, which
currently getting its information from configuration manager, but
there's also plan to get that info from MySQL. In any case, the
structures in HostMgr and HostDataSource are static and are considered
part of the configuration. Those host structures are defined only for
hosts that an administrator make reservations for.

What is needed for secure is a dynamic structure that will be
dynamically created for all hosts, regardless if there's a reservation
for it or not. I chatted about this with Marcin a bit and we came to a
conclusion that secure is only the first usage for this sort of
structure and there will be others. To be more specific, here are the
use cases I can envision for such a dynamic structure:

- secure-dhcp: we load or generate keys for hosts that support secure.
In the first iteration, we'll support only hosts with pre-configured
keys, but later there will be TOFU case, where we can trust hosts we see
for the first time.
- reconfigure: RFC3315 says that the server is supposed to generate
reconfigure-key for each host and keep that information in case
reconfiguration is needed
- per host statistics: some time in the future we'll want to collect
statistics on a per host basis. That could be used for billing, but also
for rate control (or stateful firewall if you want to call it that)

The major difference is the lifecycle of said Host structure. For
configuration, we keep it in the configuration for all hosts for the
whole time, until server reconfigugration or shutdown. For reconfigure
case, the structure is dynamically created when the host acquires its
first lease. For secure-dhcp, it depends. If the host was pre-configured
with static key or cert, we keep the info as with other static
reservations. If it was not and does TOFU instead, we may need to create
such a structure dynamically.

I think ultimately, we'll need to keep that information in the database,
similar to how we store leases. In particular, we need persistence of
that data across restarts. For example, once a reconfigure-key is
generated and communicated to the host, the server needs to remember it
even after the server restart.

The naive approach would be extend lease database with extra columns for
secure and later for stats. That would be a poor choice for several
reasons. First, there is a single host that may have multiple leases.
Keeping that info in leases would bring a huge data discrepancy between
leases. Second, there will be cases where host is preconfigured with key
or cert, but doesn't have any leases yet.

So what I think is feasible for now is to engineer the host holding
information in a way that allows basic cases now, while being extensible
in the future to cover more advanced ones.

Francis proposed a TSHost (temporary state) structure that is derived
from the base Host structure. I think that's a good start. I haven't
reviewed the code in details, but I think what is missing is the ability
to dynamically remove the structure once it is no longer needed. This is
possibly something we could develop at a later date (say we don't
support TOFU now, just statically pre-provisioned keys/certs). That's
fine for now, but the design should cover it.

The design is here: http://kea.isc.org/wiki/SecureDHCPv6
The code is on sedhcpv6a branch.

Thoughts? Comments?

Tomek


More information about the kea-dev mailing list