Federated wireguard network idea
Any feedback welcome.
Let’s keep things stupidly simple and simply hash the domain name to get a unique IPv6 ULA prefix.
Then we would need a stupidly simple backend application to automatically fetch pubkeys and endpoints from DNS and make a request to add each others as peers.
Et voilà, you got a worldwide federated wireguard network resolving private ULA addresses. Sort of an internet on top of the internet .
The DNS entries with the public IPv4 / IPv6 addresses could even be delegated to other domains / endpoints which would act as reverse proxy (either routing or nesting tunnels) for further privacy.
Maybe my approach is too naïve and there are flaws I haven’t considered, so don’t be afraid to comment.
Exact use cases? Idk, but it sounds nifty.
#privacy #networking #VPN #wireguard #infosec
cc: @fediverse
deleted by creator
@despotic_machine thank you. This sounds interesting!
@fediverse I’ve read that this is called an overlay network. Unfortunately many of the ones I’ve seen documented focus on keeping things in their own private networks which is okay but not fun.
ULA addresses require no permission and were designed precisely to knit together private networks. We can just use domain names and convert them via checksum into a static ULA /48 prefix. DNS can be used to announce routes, or eventually something more BGP-like given that ownership of a domain can be verified and thus authorization to announce routes.
If domains ever become a bottleneck one could use private TLDs with some consensus mechanism and even create multi-layer networks this way where packmates.layer.1 and packmates.layer.2 are two different networks even though they might have the same address range.
Anyways, I’ll go out and touch some grass now.
https://github.com/ivpn/desktop-app/issues/290
I made this feature request to IVPN. I doubt IVPN will make it happen but I also did it to get the idea out there. I do think IVPN clients are the best FOSS VPN clients on the market and the idea was to fork IVPN desktop and mobile clients and modify them to bee these universal VPN clients were any VPN provider can integrate these clients into their service. This way a user can subscribe to a few or several VPN providers and access them all in one client, easy to add providers in the client. All a user needs to do is add a URL or IP address in the subscription settings of the VPN client, and login to the VPN account and from there the VPN client will import the VPN servers that VPN providers has and always keep them up to date when the VPN providers adds or remove servers.
Also such an idea will ensure there is a one, secure and fully open source VPN client that works with many VPN providers, and VPN providers do not need to spend time and money developing their own clients for desktop and mobile, and can instead spend time and money on their service and servers. VPN providers can contribute to the universal VPN client if they so wish.
What security implications does this involve?
@Wander @fediverse neat. sounds a bit like dn42, only federated and I am guessing without transit/routing to other users you aren’t directly peered with?
@nysepho @fediverse there would be routing without being peered directly by delegating your endpoint to another peer you trust (this can create an infinitely long routing chain depending on where you latch on so to speak, but you would be in control)
Routing would be the hard bit I expect… if the person you were communicating was 10 hops away how to find the route? Things like BGP do that naturally, but really you don’t want to burden potentially nontechnical users with BGP…
