Here are two mailing list posts I’ve done in the past couple weeks. It’s an overall roadmap for a vision I’ve been working on for the past few years.
Enjoy.
Phase 1: FreedomBox
Hello all,
I want to share with folks what my idea for the freedombox is and how I’m continuing to work on achieving that goal. I’m a systems guy and so I am a very practical, feet on the ground kind of person. As such this e-mail will be somewhat low level and tactical, hopefully that will lead to some productive discourse. 
I have thoroughly enjoyed the numerous deep, if not somewhat theoretical conversations on this list about security,encryption,naming system changes,p2p etc. I do have a test lab and am looking forward to playing with this stuff as it comes into fruition.
To contribute to that , I’m currently thinking through how to utilize things like GENODE for a trusted code base on the bottom and run various pieces inside Debian guests. As I work more with that idea I’ll post up my adventures.
As for my idea of the FreedomBox:
In a nutshell I want to create a debian meta package called ownyourdata and in one single apt-get command have it build,deploy,defend an integrated free software stack that provides secure (anonymity, defensibility), encrypted (storage and transit), sustainable (encrypted local and friend cloud backups), federated (can’t be an island) data ownership capabilities.
This would make it available to anyone running a Debian system on whatever hardware platform they
choose. It would also make it easy for anyone performing integration tasks (tech savy folks setting this up for their social network, hardware/software vendors that we might partner with, NGOs etc).
The overall meta package would consist of some sub meta packages:
dataown-web (LAMP frontend applications mentioned on my wiki. Easily re mixed with whatever LAMP apps folks choose to substitute).
I’ve been working on this pieces for the past 18 months or so, and the current incarnation of my idea is documented at http://wiki.knownelement.com/index.php?title=Data_Ownership
That page covers the process of getting off the cloud and onto ones own server. I’ve gotten all my data off the cloud, though I do utilize a hosting provider, as I’m no longer interested in maintaining a server/network farm at home for production use.
I am happy with the software choices I’ve used for that migration. It’s taken a few iterations to find the software I like. That’s the beauty of free software, having those choices and being able to easily change between them.
I think most of us are already at this point (data migrated off of cloud onto LAMP stack under various degrees of our control). I want to make a debian package that can allow anyone to get to that same point very quickly. I feel that I’ve used these packages enough that I can strongly recommend them to other people.
dataown-backends Package up various support daemons (XMPP/LDAP/Gnump3d)
This is additional functionality that most people would want to utilize. It’s something that is on my very near term todo list for my own use. Should be pretty easy to package up.
dataown-backups (Tahoe-lafs, maybe duplicity?)
This is where I am now focused. Working on bullet proof automatic, network local backups using duplicity and dumping into a Tahoe-lafs grid, as well as p2p cloud backups with friends utilizing Tahoe-lafs and maybe Phanthom/n2n. It’s certainly a work in progress. I’ll keep track of the work on my wiki at http://wiki.knownelement.com/index.php?title=BlueJacket It’s actually proving to be a somewhat difficult problem to wrap my head around. Well the problem is simple, but numerous solutions exist that require detailed analysis.
Once I’ve got the backups solid I will move on to security work. I’m hoping to post a complete write up on my backup solution by the end of April.
Ideally I can create all 3 above packages sometime in May.
dataown-security (Kerberos/One Time Password generation bits/TOR/Phanthom/I2P)
This is something that will require substantial attention, analysis, testing, user feedback etc. In short I feel it’s where the FreedomBox will truly shine. I don’t expect it to be easy, and in fact expect the first beta incarnation to take 6 months or so. We can bring “enterprise grade” security to everyone at a vastly lower cost (no additional cost beyond hardware)/complexity then existing solutions.
What do folks think of this idea?
Phase 2: Network architecture for the freedombox to communicate over
Hey folks,
I have really enjoyed the discussion on the list over the past few days. Great stuff. Got me thinking.
I suppose I owe you folks a big long post on what I think the “next net” should look like, just like I posted my vision and work towards implementing the FreedomBox vision. My vision is mostly focused on utilizing the existing networks until we have enough systems deployed to build our own. These systems will need to be built with a vision towards interop and joining a larger p2p cloud at some future point.
Keep in mind I’m not really able to implement any of this “next net’ vision until I’m done with my FreedomBox work (backups/distributed system/security). I’ve made a commitment to myself to get that stuff shipped.
This is where you fine folks come in. Hopefully we can all proceed in parallel and rapidly release a coherent system that can be deployed in a grassroots manner.
I’m targeting beta 1 release of my security stack stuff for ContactCon October 20th 2011. *waves at Vanessa*. Having a date/conference really focuses me and drives me to produce something that I can toss out for folks to hack on. Would love to have some slides in my presentation that talk about the progress on the network portion of our overall vision. Not sure if I’ll be able to make it to the con, but I can certainly participate virtually.
Essentially I don’t want all the work folks are doing on FreedomBox to be obsolete due to a centrally administered network that can take them out. In short the parallel/alternative/nextnet network is the most important piece.
This is kind of rough but here goes my vision/roadmap…
Phase 1: access layer and the distribution layer via mesh networks. Using 802.11a/g/n and 3650mhz.
It will be different region by region. I have a good idea how to cover most of Southern California (where I was born and lived for 25 years). I have war driven a fair amount and done lots of GIS type research. You can get a 1gig .shp file of LA county for $8.00 on a DVD. Then you can do all sorts of things with it, in programs like UDIG ( http://udig.refractions.net/ ) The FCC provides .shp files as well, if you want to know where towers and licensed links are etc. USGS has data on topography etc. NASA, Microsofts TerraEarth etc etc. Lots of GIS data out there for free. Use things like http://www.qsl.net/kd2bd/splat.html to do link planning. I’ve been doing this stuff for a while now and have been focused on building real networks. It’s great to talk about theory, perfect world, IP is broken, replacing TCP/IP etc, but in the end it’s really not practical. However I’m not opposed to replacing layer2 in wifi. See http://tier.cs.berkeley.edu/drupal/wireless for folks who are building a TDMA based layer2 on openwrt/wrt54gl boxes.
Other regions have different geography and that needs to be taken into account. Perhaps folks can start finding local organizations that will give roof space etc?
I am thinking of building a localized advertising network, so the below bits include revenue percentages. They add up to 50%. This keeps costs way down, because neighborhood folks are keen to keep the network up and running to maintain advertising cash flow. Capitalistic, mod me down etc etc.
SoCal Region Network/Revenue Plan (feel free to take this and adapt to your region). It was original written from a proprietary perspective. I’ve done minimal editing here to make it less so. It’s available under the public domain. All rights assigned to everyone etc etc.
OSS:
This is a highly available system with primary hosting at a regional HQ of sorts
(probably a local hackerspace) and fully
redundant backup on two ec2 or other IASS provider availability zones.
It contains the network command and control systems used for provisioning,
billing,monitoring,authentication, ad delivery etc.
Packet pushing:
The packet pushing functions of the network are split into 5 layers:
1) Network core POP location (horizontal/distributed network core layer)
These are located in computer rooms on mountain tops throughout southern
California. These locations terminate bridged Black Diamond PtP back haul
links over 3650 and whitespace frequencies.
These points of presence consist of:
A) vyatta based x86 rack mount systems
B) switching gear
C) UBNT.com 3650 and 700mhz antennas
2) Network Aggregation POP Location (horizontal/distributed network aggregation layer)
(Black diamond nodes) (30% revenue sharing)
These are located in peoples houses that have been early adopters and are willing to take on the
burden of a nascent network.
They host an AP/switch, iboot, ups, sheeva plug, x86 ad server. All contained in a locked box
with only the antennas/connectors exposed.
3) Network Distribution POP Location (horizontal/distributed network distribution layer)
(Green diamond nodes) (15% revenue sharing)
mesh gateway ap
4) Neighborhood POP
(Blue diamond nodes – mesh client ap) (4% revenue sharing)
5) Block POP
(Red diamond nodes in home ap) (1% revenue sharing)
Phase 2: Linking up regional networks (at least one per state, probably one per city/county). By this I mean one regional network. There will be many many many meshes setup, in varying degrees of coverage, bandwidth, backhaul characteristics etc. They will rapidly converge into regional networks and interconnect via some sort of external gateway protocol (probably BGP but maybe not). This allows the individual networks to stay small, agile, independent (avoiding becoming a conglomerate that can be easily shut down), but to interconnect/peer with each other to implement regional traffic flow etc.
I would like to see a network wide system utilizing:
n2n for tunneling traffic between local and regional networks across the existing backbone in a transparent method as possible. Some MTU hit would be taken, but I think this is acceptable.
Phanthom/Tor/I2P for full end to end encryption/privacy/anonymity. No one should be more powerful
or trusted then anyone else. Some centralization might be required (for example hosting a distributed hash table with a directory of nodes). I would like to avoid that, and I can certainly make it optional. So a network could operate on a pure localized peer to peer basis. A wizard could ask something like “do you wish to connect your cloud with other clouds on a global basis?” Dunno. Something to think about. I feel that a small amount of centralized infrastructure that leads to rapid boot strapping is a useful thing.
MPLS for making the back bone scale. Not sure if this is strictly necessary, but it seems like a cool idea. I’ve not done enough with MPLS in a pure software routing environment to know if it’s a workable state or not. Google did a presentation at the last NANOG on the subject that seemed to make it look like it was workable for them at a large scale http://nanog.org/meetings/nanog50/abstracts.php?pt=MTYzNSZuYW5vZzUw&nm=nanog50 <http://nanog.org/meetings/nanog50/abstracts.php?pt=MTYzNSZuYW5vZzUw&nm=nanog50>
Phase 3: Linking up with the rest of the world. Not sure how to go about this. This is where the global entity comes in. The rest of the world uses BGP to send route announcements around. We would need
an entity for the AS and IP space to be assigned to.
So that’s about the totality of my vision for now. It’s how I plan to implement the road map that Isaac laid out the other day. Please attack each and every aspect of this and make it awesome!
Setup snort