[kea-dev] Moving forward with secure-dhcp6

[Francis Dupont]

Tomek Mrugalski writes:
> 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.

=> I have prepared 2 tickets for this: one with the changes in the current
code (which has some bugs), a second for the new code (i.e., asym crypto).

=> you missed the Timestamp support in libutil (independent so easy
but we need to agree about the format first. Note we have both codes :-).

> 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.

=> to summary the problem: we need a place to put the timestamps so
we can check if a received message is a replay or not. I extend
the Host object with a temporary state as suggested by Marcin but
they are other ways to code this.

> 3. Configuration parsers for secure details (keys, certs)

=> this part is ready (but is a matter of taste too).

> 4. Use of all that infomation in src/bin/dhcp6.

=> this is a few large pieces of code with known entry points.
BTW it will require a large amount of unit tests (not hard to write
but boring :-).

> 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.

=> as you wrote the hard issue is how to use this to implement TOFU.
I have some ideas but I wait for the DB data source...

> 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.

=> note you can implement TOFU at the key/cert store too: it will work
only for known clients (kea hosts) but it is transparent at the kea
configuration level.

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

=> thanks. BTW we have the DHCPv4-over-DHCPv6 too (and this one is
already published in a RFC).

Francis Dupont <fdupont at isc.org>