OOB and accounting - state of things

[Riccardo Paolo Bestetti]

Hello,

I would like to explore the possibility to integrate this into a large-scale (XaaS or corporate) solutions (mostly for curiosity - for now). The main extra functionality I'm seeking is IP address management and accounting options. These are currently achieved in OpenVPN with various configuration options and --client-connect/--client-disconnect hooks. While it isn't a particularly clever system, it usually gets the job done: it helps to receive IP configuration from the remote side, it provides a mechanism for authorization (username/password/static challenge) and it spits out notifications on peer connect and disconnect.

A more clever (and less messy) way to go at this it probably to just implement an OOB communication and let userspace software deal with all of this. Ideally, this would work even before IP configuration. (For reference, it was suggested here [1] that a bootstrap IP address could currently be used to obtain an analogous result - I disagree, as it is not OOB and it is devious.)
As a (prospected) systems integrator, this would be a terrific tool to have, especially because existing solutions either suck (OpenVPN) or are not particularly widespread (tinc).

Examples of how this could work:

A. Client "road warrior" access to a network, with "push" IP configuration.
The client userspace program (CUP?) would send the network's WireGuard peer through the OOB interface a request to access the network. The server userspace program (SUP? ^^) would reply by requesting whatever authorization information it wants (username/password/2FA/OAuth/whatever). The CUP would provide that, and the SUP, upon verification of the information, would provide the client with IP configuration (wg interface IP address, routes, etc.), and would dynamically configure the Cryptokey Router to begin accepting packets from that IP address, from the particular client. After that, a keepalive mechanism could be used, and upon failure, the SUP could reconfigure the Cryptokey Router to stop accepting such packets (i.e. annul the authorization).

B. Site-to-site access to a network
This is a use case I currently have with a client of mine. They use IPsec and it's a configuration nightmare, especially when we need to change IP addresses on our side (we can't use NAT because of poor strongSwan support, which is btw something that is fixed for free with the transparent wg network interfaces, and also because their SaaS provider still needs transparent access to some addresses on the client's side).
This could work similarly to the previous example (possibly without authorization - it wouldn't make that much sense in a more static setup), except the CUP could be able to advertise a new IP configuration on its side and the SUP would configure the Cryptokey Router (and the system routing table, if needed) accordingly.

What do you think? Is there any work being done already?

BR,
Riccardo


[1] https://lists.zx2c4.com/pipermail/wireguard/2017-February/001056.html