-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Nick,
This sounds pretty solid. A few questions - sorry if these have already been covered: * How does Alice discover who Bob's buddies are and stay up-to-date with their IP addresses (since presumably buddies might also have dynamic addresses)? * Is there any form of revocation if Bob stops trusting a buddy? * When Alice connects to a buddy, how does she tell the buddy whose ssh-vpn service she's looking for? * What happens if she asks the buddy for Carol's ssh-vpn service instead of Bob's? * When Alice receives an ssh-vpn service location from Bob's buddy, how does the buddy (or Alice) know the IP address provided by the buddy is up to date? Cheers, Michael On 26/06/12 02:44, Nick M. Daly wrote: > 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 > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJP6XvMAAoJEBEET9GfxSfM2xIIAKkejKp76OTI4P+lGVB5nZGJ yDl9ovgnxLmya9+F0pK69WhLT7yK1FMMYUYUvbXKOV1kmPWT6PtFaSd5hO/1urAF ESX0GVzUqOmYhmwuL6uV+Vq1GYmU1FQ2/8GCmI0nj4hgynX6Ryx3FWe62HbTeask 7TV/quK0riqkOH4Sz8zBG2t9RwVi7ptXpW42CQhM5bxFkoH5+i3G84Z8T1Y3mHqt i+mMlZ1558stvSdDn6A7ZLrqEm/jeUkTFyR2wNGhBtWhRWcH6/aXpHapUNZbHS2n KF/qdGT87pNjXkJ3xsqzlRUAFN7mYgSdTrIPeHaLHaIPZeP2B7VlNLwOcsf0XZw= =vjVu -----END PGP SIGNATURE----- _______________________________________________ Freedombox-discuss mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
