[Freedombox-discuss] Request for Comment: FreedomBuddy-VPN Setup

[Michael Rogers]

-----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 Freedombox-discuss at lists.alioth.debian.org 
> 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-----