- cypherpunks-legacy - lists.cpunks.org

Re: Public Key Infrastructure: An Artifact...
by None 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- At 04:47 PM 11/22/00 -0800, Bram Cohen wrote: >On Wed, 22 Nov 2000 Lynn.Wheeler(a)firstdata.com wrote: >>the other scenerio that some certification agencies have >>expressed (i.e. licensing bureaus, bbb, consumer report, etc >>operations) is that in the online world ... that they would >>provide an online service .... rather than certificates >>designed for an offline world. >Yes, it seems fairly well established that revocations just >plain don't work. >Once again, the solution to the problems of offline >operation appears to be online operation. And the annoying thing about this is that once we go to needing an online trusted third party to allow us to have secure communications, we may as well chuck the public key stuff and just use symmetric ciphers and the key exchange protocols worked out ten or fifteen years ago. Which makes me suspect that we're just not using public key mechanisms very intelligently yet. We've realized that screws are better for many jobs than nails, it's just that they're so damned hard to hammer in.... >-Bram Cohen --John Kelsey PGP: 5D91 6F57 2646 83F9 6D7F 9C87 886D 88AF ``Slavery's most important legacy may be a painful insight into human nature and into the terrible consequences of unbridled power.'' --Thomas Sowell, _Race and Culture_ -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.1 Int. for non-commercial use <http://www.pgpinternational.com> Comment: foo iQCVAwUBOh7WlyZv+/Ry/LrBAQE+eAP9E8RxIl9TAVbWT8CJKGl0V3IN9wMCWs82 wzh3XaSs/YYdGcG/+rEPN+S6y9t8HsSz9vr3dgPwOMDsVvkmBkOQJT+YK86thUiS a4eL2Ea9T2lAj5+gb6jeUhBpqn130C0WxUab5ARZffSOMkZCa7I9V6CfKIwL9Noq fMzDtrkqNXw= =yGFp -----END PGP SIGNATURE-----

1 0

Re: Public Key Infrastructure: An Artifact...
by None 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- At 04:47 PM 11/22/00 -0800, Bram Cohen wrote: >On Wed, 22 Nov 2000 Lynn.Wheeler(a)firstdata.com wrote: >>the other scenerio that some certification agencies have >>expressed (i.e. licensing bureaus, bbb, consumer report, etc >>operations) is that in the online world ... that they would >>provide an online service .... rather than certificates >>designed for an offline world. >Yes, it seems fairly well established that revocations just >plain don't work. >Once again, the solution to the problems of offline >operation appears to be online operation. And the annoying thing about this is that once we go to needing an online trusted third party to allow us to have secure communications, we may as well chuck the public key stuff and just use symmetric ciphers and the key exchange protocols worked out ten or fifteen years ago. Which makes me suspect that we're just not using public key mechanisms very intelligently yet. We've realized that screws are better for many jobs than nails, it's just that they're so damned hard to hammer in.... >-Bram Cohen --John Kelsey PGP: 5D91 6F57 2646 83F9 6D7F 9C87 886D 88AF ``Slavery's most important legacy may be a painful insight into human nature and into the terrible consequences of unbridled power.'' --Thomas Sowell, _Race and Culture_ -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.1 Int. for non-commercial use <http://www.pgpinternational.com> Comment: foo iQCVAwUBOh7WlyZv+/Ry/LrBAQE+eAP9E8RxIl9TAVbWT8CJKGl0V3IN9wMCWs82 wzh3XaSs/YYdGcG/+rEPN+S6y9t8HsSz9vr3dgPwOMDsVvkmBkOQJT+YK86thUiS a4eL2Ea9T2lAj5+gb6jeUhBpqn130C0WxUab5ARZffSOMkZCa7I9V6CfKIwL9Noq fMzDtrkqNXw= =yGFp -----END PGP SIGNATURE-----

1 0

Re: Public Key Infrastructure: An Artifact...
by None 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- At 04:47 PM 11/22/00 -0800, Bram Cohen wrote: >On Wed, 22 Nov 2000 Lynn.Wheeler(a)firstdata.com wrote: >>the other scenerio that some certification agencies have >>expressed (i.e. licensing bureaus, bbb, consumer report, etc >>operations) is that in the online world ... that they would >>provide an online service .... rather than certificates >>designed for an offline world. >Yes, it seems fairly well established that revocations just >plain don't work. >Once again, the solution to the problems of offline >operation appears to be online operation. And the annoying thing about this is that once we go to needing an online trusted third party to allow us to have secure communications, we may as well chuck the public key stuff and just use symmetric ciphers and the key exchange protocols worked out ten or fifteen years ago. Which makes me suspect that we're just not using public key mechanisms very intelligently yet. We've realized that screws are better for many jobs than nails, it's just that they're so damned hard to hammer in.... >-Bram Cohen --John Kelsey PGP: 5D91 6F57 2646 83F9 6D7F 9C87 886D 88AF ``Slavery's most important legacy may be a painful insight into human nature and into the terrible consequences of unbridled power.'' --Thomas Sowell, _Race and Culture_ -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.1 Int. for non-commercial use <http://www.pgpinternational.com> Comment: foo iQCVAwUBOh7WlyZv+/Ry/LrBAQE+eAP9E8RxIl9TAVbWT8CJKGl0V3IN9wMCWs82 wzh3XaSs/YYdGcG/+rEPN+S6y9t8HsSz9vr3dgPwOMDsVvkmBkOQJT+YK86thUiS a4eL2Ea9T2lAj5+gb6jeUhBpqn130C0WxUab5ARZffSOMkZCa7I9V6CfKIwL9Noq fMzDtrkqNXw= =yGFp -----END PGP SIGNATURE-----

1 0

Re: Public Key Infrastructure: An Artifact...
by None 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- At 04:47 PM 11/22/00 -0800, Bram Cohen wrote: >On Wed, 22 Nov 2000 Lynn.Wheeler(a)firstdata.com wrote: >>the other scenerio that some certification agencies have >>expressed (i.e. licensing bureaus, bbb, consumer report, etc >>operations) is that in the online world ... that they would >>provide an online service .... rather than certificates >>designed for an offline world. >Yes, it seems fairly well established that revocations just >plain don't work. >Once again, the solution to the problems of offline >operation appears to be online operation. And the annoying thing about this is that once we go to needing an online trusted third party to allow us to have secure communications, we may as well chuck the public key stuff and just use symmetric ciphers and the key exchange protocols worked out ten or fifteen years ago. Which makes me suspect that we're just not using public key mechanisms very intelligently yet. We've realized that screws are better for many jobs than nails, it's just that they're so damned hard to hammer in.... >-Bram Cohen --John Kelsey PGP: 5D91 6F57 2646 83F9 6D7F 9C87 886D 88AF ``Slavery's most important legacy may be a painful insight into human nature and into the terrible consequences of unbridled power.'' --Thomas Sowell, _Race and Culture_ -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.1 Int. for non-commercial use <http://www.pgpinternational.com> Comment: foo iQCVAwUBOh7WlyZv+/Ry/LrBAQE+eAP9E8RxIl9TAVbWT8CJKGl0V3IN9wMCWs82 wzh3XaSs/YYdGcG/+rEPN+S6y9t8HsSz9vr3dgPwOMDsVvkmBkOQJT+YK86thUiS a4eL2Ea9T2lAj5+gb6jeUhBpqn130C0WxUab5ARZffSOMkZCa7I9V6CfKIwL9Noq fMzDtrkqNXw= =yGFp -----END PGP SIGNATURE-----

1 0

Re: Public Key Infrastructure: An Artifact...
by None 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- At 04:47 PM 11/22/00 -0800, Bram Cohen wrote: >On Wed, 22 Nov 2000 Lynn.Wheeler(a)firstdata.com wrote: >>the other scenerio that some certification agencies have >>expressed (i.e. licensing bureaus, bbb, consumer report, etc >>operations) is that in the online world ... that they would >>provide an online service .... rather than certificates >>designed for an offline world. >Yes, it seems fairly well established that revocations just >plain don't work. >Once again, the solution to the problems of offline >operation appears to be online operation. And the annoying thing about this is that once we go to needing an online trusted third party to allow us to have secure communications, we may as well chuck the public key stuff and just use symmetric ciphers and the key exchange protocols worked out ten or fifteen years ago. Which makes me suspect that we're just not using public key mechanisms very intelligently yet. We've realized that screws are better for many jobs than nails, it's just that they're so damned hard to hammer in.... >-Bram Cohen --John Kelsey PGP: 5D91 6F57 2646 83F9 6D7F 9C87 886D 88AF ``Slavery's most important legacy may be a painful insight into human nature and into the terrible consequences of unbridled power.'' --Thomas Sowell, _Race and Culture_ -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.1 Int. for non-commercial use <http://www.pgpinternational.com> Comment: foo iQCVAwUBOh7WlyZv+/Ry/LrBAQE+eAP9E8RxIl9TAVbWT8CJKGl0V3IN9wMCWs82 wzh3XaSs/YYdGcG/+rEPN+S6y9t8HsSz9vr3dgPwOMDsVvkmBkOQJT+YK86thUiS a4eL2Ea9T2lAj5+gb6jeUhBpqn130C0WxUab5ARZffSOMkZCa7I9V6CfKIwL9Noq fMzDtrkqNXw= =yGFp -----END PGP SIGNATURE-----

1 0

Re: Public Key Infrastructure: An Artifact...
by None 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- At 04:47 PM 11/22/00 -0800, Bram Cohen wrote: >On Wed, 22 Nov 2000 Lynn.Wheeler(a)firstdata.com wrote: >>the other scenerio that some certification agencies have >>expressed (i.e. licensing bureaus, bbb, consumer report, etc >>operations) is that in the online world ... that they would >>provide an online service .... rather than certificates >>designed for an offline world. >Yes, it seems fairly well established that revocations just >plain don't work. >Once again, the solution to the problems of offline >operation appears to be online operation. And the annoying thing about this is that once we go to needing an online trusted third party to allow us to have secure communications, we may as well chuck the public key stuff and just use symmetric ciphers and the key exchange protocols worked out ten or fifteen years ago. Which makes me suspect that we're just not using public key mechanisms very intelligently yet. We've realized that screws are better for many jobs than nails, it's just that they're so damned hard to hammer in.... >-Bram Cohen --John Kelsey PGP: 5D91 6F57 2646 83F9 6D7F 9C87 886D 88AF ``Slavery's most important legacy may be a painful insight into human nature and into the terrible consequences of unbridled power.'' --Thomas Sowell, _Race and Culture_ -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.1 Int. for non-commercial use <http://www.pgpinternational.com> Comment: foo iQCVAwUBOh7WlyZv+/Ry/LrBAQE+eAP9E8RxIl9TAVbWT8CJKGl0V3IN9wMCWs82 wzh3XaSs/YYdGcG/+rEPN+S6y9t8HsSz9vr3dgPwOMDsVvkmBkOQJT+YK86thUiS a4eL2Ea9T2lAj5+gb6jeUhBpqn130C0WxUab5ARZffSOMkZCa7I9V6CfKIwL9Noq fMzDtrkqNXw= =yGFp -----END PGP SIGNATURE-----

1 0

Re: Public Key Infrastructure: An Artifact...
by None 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- At 04:47 PM 11/22/00 -0800, Bram Cohen wrote: >On Wed, 22 Nov 2000 Lynn.Wheeler(a)firstdata.com wrote: >>the other scenerio that some certification agencies have >>expressed (i.e. licensing bureaus, bbb, consumer report, etc >>operations) is that in the online world ... that they would >>provide an online service .... rather than certificates >>designed for an offline world. >Yes, it seems fairly well established that revocations just >plain don't work. >Once again, the solution to the problems of offline >operation appears to be online operation. And the annoying thing about this is that once we go to needing an online trusted third party to allow us to have secure communications, we may as well chuck the public key stuff and just use symmetric ciphers and the key exchange protocols worked out ten or fifteen years ago. Which makes me suspect that we're just not using public key mechanisms very intelligently yet. We've realized that screws are better for many jobs than nails, it's just that they're so damned hard to hammer in.... >-Bram Cohen --John Kelsey PGP: 5D91 6F57 2646 83F9 6D7F 9C87 886D 88AF ``Slavery's most important legacy may be a painful insight into human nature and into the terrible consequences of unbridled power.'' --Thomas Sowell, _Race and Culture_ -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.1 Int. for non-commercial use <http://www.pgpinternational.com> Comment: foo iQCVAwUBOh7WlyZv+/Ry/LrBAQE+eAP9E8RxIl9TAVbWT8CJKGl0V3IN9wMCWs82 wzh3XaSs/YYdGcG/+rEPN+S6y9t8HsSz9vr3dgPwOMDsVvkmBkOQJT+YK86thUiS a4eL2Ea9T2lAj5+gb6jeUhBpqn130C0WxUab5ARZffSOMkZCa7I9V6CfKIwL9Noq fMzDtrkqNXw= =yGFp -----END PGP SIGNATURE-----

1 0

Re: Public Key Infrastructure: An Artifact...
by None 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- At 04:47 PM 11/22/00 -0800, Bram Cohen wrote: >On Wed, 22 Nov 2000 Lynn.Wheeler(a)firstdata.com wrote: >>the other scenerio that some certification agencies have >>expressed (i.e. licensing bureaus, bbb, consumer report, etc >>operations) is that in the online world ... that they would >>provide an online service .... rather than certificates >>designed for an offline world. >Yes, it seems fairly well established that revocations just >plain don't work. >Once again, the solution to the problems of offline >operation appears to be online operation. And the annoying thing about this is that once we go to needing an online trusted third party to allow us to have secure communications, we may as well chuck the public key stuff and just use symmetric ciphers and the key exchange protocols worked out ten or fifteen years ago. Which makes me suspect that we're just not using public key mechanisms very intelligently yet. We've realized that screws are better for many jobs than nails, it's just that they're so damned hard to hammer in.... >-Bram Cohen --John Kelsey PGP: 5D91 6F57 2646 83F9 6D7F 9C87 886D 88AF ``Slavery's most important legacy may be a painful insight into human nature and into the terrible consequences of unbridled power.'' --Thomas Sowell, _Race and Culture_ -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.1 Int. for non-commercial use <http://www.pgpinternational.com> Comment: foo iQCVAwUBOh7WlyZv+/Ry/LrBAQE+eAP9E8RxIl9TAVbWT8CJKGl0V3IN9wMCWs82 wzh3XaSs/YYdGcG/+rEPN+S6y9t8HsSz9vr3dgPwOMDsVvkmBkOQJT+YK86thUiS a4eL2Ea9T2lAj5+gb6jeUhBpqn130C0WxUab5ARZffSOMkZCa7I9V6CfKIwL9Noq fMzDtrkqNXw= =yGFp -----END PGP SIGNATURE-----

1 0

My vision for what the distributed-decentralized-internet should be
by Charles N Wyble 06 Jul '18

06 Jul '18

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=nano… <http://nanog.org/meetings/nanog50/abstracts.php?pt=MTYzNSZuYW5vZzUw&nm=nano…> 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! ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

My vision for what the distributed-decentralized-internet should be
by Charles N Wyble 06 Jul '18

06 Jul '18

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=nano… <http://nanog.org/meetings/nanog50/abstracts.php?pt=MTYzNSZuYW5vZzUw&nm=nano…> 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! ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0