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

[Jonathan Wilkes]

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 <nick.m.daly at gmail.com>
> To: freedombox-discuss at lists.alioth.debian.org
> 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
> Freedombox-discuss at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
>