Provisioning arrangements for secnet - consultation

[Ian Jackson]

secnet's currently provisioning arrangements (eg, new site enrolment)
are unsatisfactory.  (The situation is worse within the SGO VPN, where
multiple protocols operate in parallel.)


I am starting by collecting requirements `user stories' [1].  I will
reply to this message with a couple of my own.  Please do likewise,
posting to sgo-software-discuss.


In the meantime, here is some more of my thinking.

IMO defects of the current arrangements include:

 * There is no automatic propagation of changed information about
   one node (perhaps a new node) to other nodes.

 * There is no support for key rollover. [*]

 * It is not easy to add support for new public-key-crypto
   algorithms.  (Eg, ECDH.)  [*]

 * There is little support for interaction with `foreign' (non-secnet)
   vpn systems (which the secnet VPN needs to know about because
   secnet is normally responsible for within-secnet-VPN routing).

 * It is difficult to provision mobile nodes in a sensible way.  I
   have been doing this manually (ie by writing bits of secnet.conf
   without the help of make-secnet-sites).

 * There are too many manual steps in most provisioning operations.

 * There is no machine-readable input and output from the provisioning
   systems, which might be used to drive other tooling.

 * It is difficult to implement a client supporting semiautomatic
   enrolment (eg for a mobile phone).

 * There is no support for IPv6 literals as public endpoint addresses.

 * Provisioning changes require a secnet restart and are disruptive to
   all of a site's peers [*].

 * There is no support for conveying IPv6 within the VPN. [2]

 * It's insufficiently extensible.


My current intent is to solve these problems by designing and
implementing new protocol(s) and a new toolset, which will completely
replace `make-secnet-sites'.

I will implement additional features in secnet proper if necessary
(for example for items [*] above), but I do not currently intend to
make significant changes to secnet proper.


I do not currently intend to put significant effort into provisioning
compatibility.  Within the SGO VPN I intend to ask everyone to
re-provision their networks using existing keys and addresses, and
generate a prospective new configuration which can be inspected and
tested (on a per-site basis).

Ultimately after some tests there will be a changeover day for each
site, when that site switches from consuming the configuration
generated by make-secnet-sites to consuming the output of the new
arrangements - but this will hopefully not need coordination.

chiark will have to have defined test periods and ultimately a
sysadmin-defined deployment date.


[1] A bit like this  https://en.wikipedia.org/wiki/User_story

[2] As part of this work I do not intend to update secnet proper to
support transport of IPv6.  But I do intend to think about conveyance
of information about in-VPN IPv6 in the new provisioning system and be
able to ignore it or filter it out when generating configurations for
current versions of secnet.  That way when IPv6 is implemented there
will be no need to update old consumers of provisioning data before
the new data can be provided.

-- 
Ian Jackson <ijackson at chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.