n2n (by alaric)
The principle is simple: one runs "supernode" servers on machines with static IP addresses - any machines; being a supernode does not mean actually joining any VPNs. Then machines that wish to join networks run the edge node software, which connects to a supernode (or, if it's down, another supernode) and registers itself. The edge node application creates a virtual Ethernet interface on the computer it runs on, which represents the VPN; and when the computer tries to send traffic down that interface, the edge node app consults the supernodes to find out where the destination computer is, and tries to send the encrypted compressed traffic directly to it. Things like NAT might prevent this from happening, in which case a supernode can help by relaying the traffic; but the encryption happens between the edge nodes, with the supernode not actually knowing the encryption key in use, and thus unable to snoop on the traffic.
Also, you can run several VPNs over the same network of supernodes. Each edge node may join any number of VPNs. The VPNs are identified by a name, making it all very easy to set them up; just use the same name and encrypted key on two edge nodes that are talking to the same supernode - or two supernodes that are talking to each other - and hey presto, you have a new network.
So I'll probably be able to run supernodes on my isolated server and the well-connected of the two private networks, and then run the isolated server, the routers to the two private networks, and the laptops as edge nodes, with the private network routers routing between the n2n VPNs and the physical private networks. I'll run several VPNs with varying levels of trust, routed between. And it will automatically route traffic directly between networks rather than through a central hub, and it'll deal with the failure of any of my networks, still allowing the survivors to communicate.
I like it!
Pages: 1 2
Crypto / security | alaric | 
Tue 6th May 2008 11:05 pm
Subscribe