Provisioning arrangements for secnet - consultation

[Ian Jackson]

Ian Jackson writes ("Provisioning arrangements for secnet - consultation"):
> 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.

User story: New laptop

 Sarah has got a new laptop.  It is running a Debian derivative.

 Sarah wants her laptop to have a VPN connection to her house network,
 and to the SGO VPN, even when it is not in the house.

 Sarah selects chiark to be her proxy for use out of the house, but
 when she's at home she wants to avoid data "tromboning" in and out of
 the house.

 She runs
    secnet-create-vpn --mobile-proxy
 on her house server.  This asks her some questions about how her
 network and DNS are set up, and enables proxyarp on the house
 server's local ethernet interface.  It generates a file `thyme.vpn'
 in /etc/secnet, which contains information about her house network
 and (references to?) information about the SGO VPN.

 Sarah installs secnet on her laptop with dpkg -i.

 Jennifer copies `thyme.vpn' from on her house server onto the laptop.
 She then runs
    secnet-join-vpn ./thyme.vpn

 secnet-join-vpn asks Jennifer some basic questions, automatically
 guessing good default answers.

 One of the questions asks for Jennifer's permission to route any or
 all of 172.16/12 and 192.168/16, apart from her own network, to the
 SGO VPNs, and all of her own network range to her house.

 secnet-join-vpn communicates with the provisioning service on her
 house server.

 The provisioning service on her house server allocates an IP address
 from a subrange of her house network which she has set aside for this
 purpose.  (Or perhaps Jennifer selects the address manually.)
 (Ideally the provisioning service will set up forward and reverse DNS
 somehow.)

 secnet-join-vpn then talks to chiark.  It then sets up secnet right
 away, expecting that things will start working when the other end is
 done.  (It is idempotent.)

 The provisioning service on chiark sees that this is request falls
 within Jennifer's existing delegation.  It emails Jennifer a
 confirmation and automaticaly incorporates the new node into chiark's
 configuration.

 The provisioning service on her house server sees somehow that
 Jennifer is authorised, and incorporates the new node into her house
 server's configuration.
 
 Communication between Jennifer's new laptop and chiark's secnet, and
 her house's secnet, starts working right away.

 When the link comes up, the provisioning system on chiark emails
 Jennifer to let her know that the provisioning was success.
 (vpn-coordinator does not need to receive a copy of this email.)

 The provisioning system realises that information about Jennifer's
 house should not be distributed to all the other nodes on the VPN.
 Instead, those other nodes will talk via Jennifer's house server,
 because the IP address is within her house server's range.

Ian.

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