Sounds exciting! What happens if Alice asks Bob about a service he is running but hasn't given her permission to use?
-Jonathan ----- Original Message ----- > From: Nick M. Daly <[email protected]> > To: [email protected] > Cc: > Sent: Monday, June 25, 2012 9:44 PM > Subject: [Freedombox-discuss] Request for Comment: FreedomBuddy-VPN Setup > > Hi FreedomBoxers, > > I'd appreciate your review and comments on the following, so I can > improve it and take any holes out before the hackfest rolls around. > > I believe this pretty effectively solves the magic routing problem, at > least between friends. This system should allow friends to organize > VPNs over dynamic IPs, without relying on the existing DNS system. > There's some hand-waving here, because a lot of the underlying system is > documented elsewhere [0]. Let me know if things are unclear or > insufficiently described. > > Alice and Bob mutually know and trust one another. Bob has previously > agreed to host a SSH VPN service for Alice. Alice now wants to connect > to Bob's VPN host. > > Alice, as the client, will run: > > $ freedombuddy-ssh-client (Bob's Key Id) > > This will: > > 1. Attmept to connect to all of Bob's ssh servers that Alice has locally > cached and trusts. > > 2. If none of those connect, Alice will iterate through each of Bob's > known FreedomBuddies, doing the following, and stopping when a > connection is successfully made: > > A. Connect to the FreedomBuddy, querying for the "ssh-vpn" service. > > B. Bob replies to Alice's requesting FreedomBuddy with zero or more > "ssh-vpn" service locations. > > C. Alice attempts to connect to each of the locations she's learned. > > Note: Alice doesn't need to carry out step 2 sequentially. She could > complete step 2 in a single burst, querying all of Bob's FreedomBuddies > at once, or sequentially, in any defined (or random) order. The current > structure doesn't support that, though, we'd need to include a random > request ID with each request (with a request-specific timeout) to > support that. Not difficult, just needs to be documented as a different > protocol version, because it's an incompatible protocol change. > > I don't believe there are any holes in that system, but I'd appreciate > your review. > > In summary: > > 1. If Alice has a list of still valid locations that start hosting for > her (through necessary heartbeat testing), we're done, she's just > connected to a working location. > > 2. If none of Alice's known locations reply, she'll query Bob's > FreedomBuddy service for new ssh locations, and then connect to > those. > > Thanks for your time, > Nick > > 0: https://github.com/NickDaly/Plinth/tree/santiago/ugly_hacks/santiago > > _______________________________________________ > Freedombox-discuss mailing list > [email protected] > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss > _______________________________________________ Freedombox-discuss mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
