- cypherpunks-legacy - lists.cpunks.org

[IP] New US Passport ID Technology Has High Error Rate
by David Farber 06 Jul '18

06 Jul '18

Begin forwarded message:

1 0

tor-ramdisk 20101207 released
by Anthony G. Basile 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone I want to announce to the list that a new release of tor-ramdisk is out. Tor-ramdisk is an i686, x86_64 or MIPS uClibc-based micro Linux distribution whose only purpose is to host a Tor server in an environment that maximizes security and privacy. Security is enhanced by hardening the kernel and binaries, and privacy is enhanced by forcing logging to be off at all levels so that even the Tor operator only has access to minimal information. Finally, since everything runs in ephemeral memory, no information survives a reboot, except for the Tor configuration file and the private RSA key, which may be exported/imported by FTP or SSH. Changelog: This release adds scp functionality using openssh-5.6p1 to export/import the configuration file and private RSA key. The build system was reworked to build dynamically linking binaries rather than static. Also, tor was updated to 0.2.1.27, busybox to 1.17.4, and the kernel to 2.6.32.25 plus Gentoo's hardened-patches-2.6.32-30.extras. i686: Homepage: http://opensource.dyc.edu/tor-ramdisk Download: http://opensource.dyc.edu/tor-ramdisk-downloads x86_64: Homepage: http://opensource.dyc.edu/tor-x86_64-ramdisk Download: http://opensource.dyc.edu/tor-x86_64-ramdisk-downloads MIPS: Homepage: http://opensource.dyc.edu/tor-mips-ramdisk Download: http://opensource.dyc.edu/tor-mips-ramdisk-downloads - -- Anthony G. Basile, Ph. D. Chair of Information Technology D'Youville College Buffalo, NY 14201 (716) 829-8197 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkz+LX8ACgkQl5yvQNBFVTUBRwCdHba3FDApV6IYlPsRKMO+bVQi picAoKQWkpUr/fZvHYylsxTUTniRfkIZ =T0CU -----END PGP SIGNATURE----- *********************************************************************** To unsubscribe, send an e-mail to majordomo(a)torproject.org with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/ ----- 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

tor-ramdisk 20101207 released
by Anthony G. Basile 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone I want to announce to the list that a new release of tor-ramdisk is out. Tor-ramdisk is an i686, x86_64 or MIPS uClibc-based micro Linux distribution whose only purpose is to host a Tor server in an environment that maximizes security and privacy. Security is enhanced by hardening the kernel and binaries, and privacy is enhanced by forcing logging to be off at all levels so that even the Tor operator only has access to minimal information. Finally, since everything runs in ephemeral memory, no information survives a reboot, except for the Tor configuration file and the private RSA key, which may be exported/imported by FTP or SSH. Changelog: This release adds scp functionality using openssh-5.6p1 to export/import the configuration file and private RSA key. The build system was reworked to build dynamically linking binaries rather than static. Also, tor was updated to 0.2.1.27, busybox to 1.17.4, and the kernel to 2.6.32.25 plus Gentoo's hardened-patches-2.6.32-30.extras. i686: Homepage: http://opensource.dyc.edu/tor-ramdisk Download: http://opensource.dyc.edu/tor-ramdisk-downloads x86_64: Homepage: http://opensource.dyc.edu/tor-x86_64-ramdisk Download: http://opensource.dyc.edu/tor-x86_64-ramdisk-downloads MIPS: Homepage: http://opensource.dyc.edu/tor-mips-ramdisk Download: http://opensource.dyc.edu/tor-mips-ramdisk-downloads - -- Anthony G. Basile, Ph. D. Chair of Information Technology D'Youville College Buffalo, NY 14201 (716) 829-8197 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkz+LX8ACgkQl5yvQNBFVTUBRwCdHba3FDApV6IYlPsRKMO+bVQi picAoKQWkpUr/fZvHYylsxTUTniRfkIZ =T0CU -----END PGP SIGNATURE----- *********************************************************************** To unsubscribe, send an e-mail to majordomo(a)torproject.org with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/ ----- 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

<nettime> Anonymous Hackers Release 90, 000 Military E-mail Accounts
by Felix Stalder 06 Jul '18

06 Jul '18

[This new tendency of dumping the full raw data onto the public networks makes WikiLeaks more editorial approach to publishing material seem positively reasonable and measured. I wonder if this is preferable to those who criticize WikiLeaks for having turned into just another information broker.] theepochtimes.com -> http://tinyurl.com/6axx57d The b hacktivistb organization Anonymous Operations posted some 90,000 military e-mail addresses and passwords, to the Pirate Bay torrent website on July 11, in what they called b Military Meltdown Monday." The organization hacked into the networks of government contracting and consulting firm Booz Allen Hamilton, where they claim to have discovered b a list of roughly 90,000 military e-mails and password hashes ... 4gb of source code,b and b maps and keys for various other treasure chests buried on the islands of government agencies, federal contractors and shady whitehat companies.b Anonymous further claims that Booz Allen was involved with several government surveillance and intelligence-gathering programs b that may be deemed illegalb and insinuate that several of Booz Allenbs executives, all former members of the Nation Security Agency, garnered illegal government favor in their private business efforts. Anonymous preceded the release with multiple lead-up tweets from several of their affiliated twitter accounts. One account, b anonymouSabu,b formerly part of the LulzSec hacking group, claims that this is the first of b two of the biggest releases for Anonymous in the last 4 years,b and sent a warning to the intelligence community, stating b Everyone brace. This is literally explosive.b Another account, b YourAnonNewsb, states that b todaybs #AntiSec release will without any doubt be the biggest release so far.b b AntiSecb or operation Anti-Security, was a collaborative effort between hacker groups LulzSec, Anonymous, and various others to attack and steal confidential information from major governments and corporations, and expose perceived corruption and abuse of power. LulzSec disbanded in late June, its members reintegrating with their original foundations in Anonymous. The websites and networks of numerous companies and government organizations have already been attacked in the name of AntiSec. Anonymous believes that their efforts are simply a form of civil disobedience, calling their tactics b peaceful protest." The government, meanwhile, has been actively trying to track down and arrest its members. Anonymous made headlines last year when they attacked MasterCard, Visa, and PayPal after the companies had suspended payments directed to the information leaking website WikiLeaks and its founder, Julian Assange. --- http://felix.openflows.com ----------------------- books out now: *|Deep Search.The Politics of Search Beyond Google.Studienverlag 2009 *|Mediale Kunst/Media Arts Zurich.13 Positions.Scheidegger&Spiess2008 *|Manuel Castells and the Theory of the Network Society. Polity, 2006 *|Open Cultures and the Nature of Networks. Ed. Futura/Revolver, 2005 # distributed via <nettime>: no commercial use without permission # <nettime> is a moderated mailing list for net criticism, # collaborative text filtering and cultural politics of the nets # more info: http://mx.kein.org/mailman/listinfo/nettime-l # archive: http://www.nettime.org contact: nettime(a)kein.org ----- 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

Re: [p2p-hackers] A globally distributed peer-to-peer data archive
by Zooko O'Whielacronx 06 Jul '18

06 Jul '18

On Fri, Aug 26, 2011 at 4:40 AM, Michael Rogers <m--(a)gmx.com> wrote: > > To be honest, I think you're asking the wrong question. It's a question I've also spent a long time asking, but it's the wrong one. Unfair resource allocation isn't what's preventing a global p2p filesystem from existing. I like the way you're thinking. > If you want to know what's actually standing in the way of a global p2p filesystem, try to persuade your technically minded friends to use Tahoe (or Freenet, or OceanStore, or CFS, or PAST, or FARSITE) for sharing files. Of the ones you listed only Freenet and Tahoe-LAFS are things you can use and are being actively developed, right? Also there is GNUnet. On the Tahoe-LAFS wiki we have a page of links to related projects [1]. > Make a note of the problems they run into and solve them all. This is something we're doing in the Tahoe-LAFS project, for example on our ticket #1024 "introductory docs are confusing and off-putting". You would be more than welcome to jump in and help. Try following the "quick start" instructions [2] and tell us how it works for you. > Repeat the process with your less technically minded friends. Once you've solved all their problems, open some champagne because you've achieved more than a decade's worth of p2p research. ;-) Heh heh. > After that, if your system's running into resource shortages, try displaying the contribution ratio in the corner of the screen with a polite reminder that higher ratios help to support the community. ;-) We have plans to do something along those lines, too: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/Ostrom Again, we'd love help! You can get major kudos points (which are redeemable for gratitude tokens and awesomeness levels) by doing some fairly simple hacks like "collect server capacities and put them on the welcome page" (ticket #648). On the other hand if Ostromism and warm fuzzy social encouragement isn't your thing, you might be able to get cold hard cash (U.S. Dollars or BitCoins) by contributing patches to Tahoe-LAFS in return for bounties. :-) Regards, Zooko [1] http://tahoe-lafs.org/trac/tahoe-lafs/wiki/RelatedProjects#OtherProjects [2] http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/quickstart.rst tickets mentioned in this letter: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1024# introductory docs are confusing and off-putting http://tahoe-lafs.org/trac/tahoe-lafs/ticket/648# collect server capacities and put them on the welcome page _______________________________________________ p2p-hackers mailing list p2p-hackers(a)lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers ----- 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

New US Passport ID Technology Has High Error Rate
by Richard Forno 06 Jul '18

06 Jul '18

Here is yet another example of security theater (the illusion of effective or enhanced security) being pursued as a matter of national security -- in this case, an unbelievable 50% error rate in the security technology being implemented is deemed acceptable enough by the US government to track passports. -rick Infowarrior.org Passport ID Technology Has High Error Rate http://www.washingtonpost.com/ac2/wp-dyn/A43944-2004Aug5? language=printer By Jonathan Krim Washington Post Staff Writer Friday, August 6, 2004; Page A01 The State Department is moving ahead with a plan to implant electronic identification chips in U.S. passports that will allow computer matching of facial characteristics, despite warnings that the technology is prone to a high rate of error. Federal researchers, academics, industry experts and some privacy advocates say the government should instead use more-reliable fingerprints to help thwart potential terrorists. The enhanced U.S. passports, scheduled to be issued next spring for people obtaining new or renewed passports, will be the first to include what is known as biometric information. Such data, which can be a fingerprint, a picture of parts of eyes or of facial characteristics, is used to verify identity and help prevent forgery. Under State Department specifications finalized this month for companies to bid on the new system, a chip woven into the cover of the passport would contain a digital photograph of the traveler's face. That photo could then be compared with an image of the traveler taken at the passport control station, and also matched against photos of people on government watch lists. The department chose face recognition to be consistent with standards being adopted by other nations, officials said. Those who drafted the standards reasoned that travelers are accustomed to submitting photographs and would find giving fingerprints to be intrusive. But federal researchers who have tested face-recognition technology say its error rate is unacceptably high -- up to 50 percent if photographs are taken without proper lighting. They say the error rate is far lower for fingerprints, which could be added to the chip without violating the international standard. < snip > The concerns come at a time of heightened terrorism alerts and urgent calls for changes in national security from the commission investigating the Sept. 11, 2001, attacks. Among its many recommendations were quick adoption of biometric passports and more secure drivers' licenses, though the commission did not specify which type of data should be used. < snip > "Facial recognition isn't going to do it for us at large scale," Wayman said. "If there's a 10 percent error rate with 300 people on a 747, that's a problem." According to tests by the National Institute for Standards and Technology, two fingerprints provide an accuracy rate of 99.6 percent. With face recognition, if the pictures are taken under controlled circumstances with proper illumination, angles and facial expression, the accuracy rate was 90 percent. < snip > ------ End of Forwarded Message ------------------------------------- You are subscribed as eugen(a)leitl.org To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0

[IP] New US Passport ID Technology Has High Error Rate
by David Farber 06 Jul '18

06 Jul '18

Begin forwarded message:

1 0

<nettime> Anonymous Hackers Release 90, 000 Military E-mail Accounts
by Felix Stalder 06 Jul '18

06 Jul '18

[This new tendency of dumping the full raw data onto the public networks makes WikiLeaks more editorial approach to publishing material seem positively reasonable and measured. I wonder if this is preferable to those who criticize WikiLeaks for having turned into just another information broker.] theepochtimes.com -> http://tinyurl.com/6axx57d The b hacktivistb organization Anonymous Operations posted some 90,000 military e-mail addresses and passwords, to the Pirate Bay torrent website on July 11, in what they called b Military Meltdown Monday." The organization hacked into the networks of government contracting and consulting firm Booz Allen Hamilton, where they claim to have discovered b a list of roughly 90,000 military e-mails and password hashes ... 4gb of source code,b and b maps and keys for various other treasure chests buried on the islands of government agencies, federal contractors and shady whitehat companies.b Anonymous further claims that Booz Allen was involved with several government surveillance and intelligence-gathering programs b that may be deemed illegalb and insinuate that several of Booz Allenbs executives, all former members of the Nation Security Agency, garnered illegal government favor in their private business efforts. Anonymous preceded the release with multiple lead-up tweets from several of their affiliated twitter accounts. One account, b anonymouSabu,b formerly part of the LulzSec hacking group, claims that this is the first of b two of the biggest releases for Anonymous in the last 4 years,b and sent a warning to the intelligence community, stating b Everyone brace. This is literally explosive.b Another account, b YourAnonNewsb, states that b todaybs #AntiSec release will without any doubt be the biggest release so far.b b AntiSecb or operation Anti-Security, was a collaborative effort between hacker groups LulzSec, Anonymous, and various others to attack and steal confidential information from major governments and corporations, and expose perceived corruption and abuse of power. LulzSec disbanded in late June, its members reintegrating with their original foundations in Anonymous. The websites and networks of numerous companies and government organizations have already been attacked in the name of AntiSec. Anonymous believes that their efforts are simply a form of civil disobedience, calling their tactics b peaceful protest." The government, meanwhile, has been actively trying to track down and arrest its members. Anonymous made headlines last year when they attacked MasterCard, Visa, and PayPal after the companies had suspended payments directed to the information leaking website WikiLeaks and its founder, Julian Assange. --- http://felix.openflows.com ----------------------- books out now: *|Deep Search.The Politics of Search Beyond Google.Studienverlag 2009 *|Mediale Kunst/Media Arts Zurich.13 Positions.Scheidegger&Spiess2008 *|Manuel Castells and the Theory of the Network Society. Polity, 2006 *|Open Cultures and the Nature of Networks. Ed. Futura/Revolver, 2005 # distributed via <nettime>: no commercial use without permission # <nettime> is a moderated mailing list for net criticism, # collaborative text filtering and cultural politics of the nets # more info: http://mx.kein.org/mailman/listinfo/nettime-l # archive: http://www.nettime.org contact: nettime(a)kein.org ----- 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

Re: [p2p-hackers] A globally distributed peer-to-peer data archive
by Zooko O'Whielacronx 06 Jul '18

06 Jul '18

On Fri, Aug 26, 2011 at 4:40 AM, Michael Rogers <m--(a)gmx.com> wrote: > > To be honest, I think you're asking the wrong question. It's a question I've also spent a long time asking, but it's the wrong one. Unfair resource allocation isn't what's preventing a global p2p filesystem from existing. I like the way you're thinking. > If you want to know what's actually standing in the way of a global p2p filesystem, try to persuade your technically minded friends to use Tahoe (or Freenet, or OceanStore, or CFS, or PAST, or FARSITE) for sharing files. Of the ones you listed only Freenet and Tahoe-LAFS are things you can use and are being actively developed, right? Also there is GNUnet. On the Tahoe-LAFS wiki we have a page of links to related projects [1]. > Make a note of the problems they run into and solve them all. This is something we're doing in the Tahoe-LAFS project, for example on our ticket #1024 "introductory docs are confusing and off-putting". You would be more than welcome to jump in and help. Try following the "quick start" instructions [2] and tell us how it works for you. > Repeat the process with your less technically minded friends. Once you've solved all their problems, open some champagne because you've achieved more than a decade's worth of p2p research. ;-) Heh heh. > After that, if your system's running into resource shortages, try displaying the contribution ratio in the corner of the screen with a polite reminder that higher ratios help to support the community. ;-) We have plans to do something along those lines, too: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/Ostrom Again, we'd love help! You can get major kudos points (which are redeemable for gratitude tokens and awesomeness levels) by doing some fairly simple hacks like "collect server capacities and put them on the welcome page" (ticket #648). On the other hand if Ostromism and warm fuzzy social encouragement isn't your thing, you might be able to get cold hard cash (U.S. Dollars or BitCoins) by contributing patches to Tahoe-LAFS in return for bounties. :-) Regards, Zooko [1] http://tahoe-lafs.org/trac/tahoe-lafs/wiki/RelatedProjects#OtherProjects [2] http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/quickstart.rst tickets mentioned in this letter: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1024# introductory docs are confusing and off-putting http://tahoe-lafs.org/trac/tahoe-lafs/ticket/648# collect server capacities and put them on the welcome page _______________________________________________ p2p-hackers mailing list p2p-hackers(a)lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers ----- 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

Re: OT: cheap colo space in Southern Germany/Munich
by Caleb James DeLisle 06 Jul '18

06 Jul '18

I really appreciate your expert opinion. It's helpful to know what I should be concentrating on. On 11/25/2012 08:22 AM, Nick Hilliard wrote: > I don't really want to get into a detailed discussion about this because > it's sunday and I have a pile of other family related things planned for > the day, but briefly: > >>>> - scaling issues >> >> It's incumbent on me to prove that it scales but if there are obvious theoretical >> scaling inadequacies then maybe you would care to bring them up? > > it looks like the design proposes a 4 bit router identifier (but flexible), > offering at most a network radius of 16 hops and a theoretical maximum of > 16 connected nodes per router. You can slide the numbers one way or > another (i.e. 32 connected nodes, at the cost of losing another bit in your > routing domain), but you can't hide from the problem that your routing > domain is too small and your bitfield allocation mechanism is far too > generous given the resource constraints inherent to it. Definitely valid. Code wise, it's pretty trivial to modify the protocol to stack headers ala MPLS. IMO we're still in an experimental stage and we need to be able to break the protocol for things just like this. > > you also have the problem that your routers are not uniquely identifiable > on any particular closed network. turns out that if they aren't uniquely > identifiable, then you open up a bunch of reachability and security problems. Routers identify each other by internal ip6 (hash of key). > >>>> >>>> - point to multipoint networking >> >> Grandma doesn't use it. > > i don't understand what you mean by this. what I mean here is that there > is no apparent mechanism for a router to talk to multiple other routers on > the same l2 broadcast domain. this is a glaring omission from the protocol. > > you also lack a link-local resolution protocol (e.g. arp / nd) It's a fair critique that that the switch layer for not offering anything remotely similar to the interface provided by Ethernet. That said, I think there's a risk in trying to analyze it in terms of Ethernet. > >>>> >>>> - that deterministic reachability is usually considered a good thing >> >> I'd love for it to be more deterministic but I don't see how to make the design do that. > > my gut feeling is that deterministic reachability can be disproved given > your design. you probably want deterministic reachability to be provable. Valid point, there is no math backing up any of this. Fortunately a router can forward to anyone it wants as long their address is numerically closer to the destination than it's own so routers in a network can experiment with different forwarding algorithms without fear of loops. > >>>> >>>> - non-local connectivity lookup introduces hilarious denial of service >>>> mechanisms >> >> Yeap, DoS is a serious issue with this design. >> It's also a serious issue (although less serious) with the Internet as it is today. >> My plan is to introduce a market based flood management system integrated with congestion control logic. >> What's your plan? >> Just hoping that that botnets never reach terrabit capacity isn't an answer. > > botnets will reach terabit capacity within the next 2-3 years. they're > currently at low hundreds of gigabits. > > re: ddos management, you're confusing a layer 9 issue (i.e. what to do with > traffic) with a layer 2 issue (i.e. how to get bits from a to b). i don't > think you can solve one problem by tweaking with the other. > >>>> >>>> - the value of bitfield qos >> >> Grandma doesn't use it. >> >>>> >>>> - that the use of bEncoding for connectivity lookup is a degree or two >>>> worse than using TLVs for the same means >> >> bEncoding sucks. But it sucks less than the alternatives which I saw at the time. >> What's necessary is simplicity and ability to add keys to a message without breaking old nodes. > > then at least use binary encoded tlvs, which have only a single layer of > indirection/translation (i.e. interpretation of what the message contains) > instead of multiple (i.e. parsing an ascii encoded message, followed by > transformation from ascii to binary, then interpretation of what the > message contains). > >>>> - full independence from traditional ip protocols ("Router messages are >>>> sent as normal UDP/IPv6 packets except that their UDP source and >>>> destination port numbers are zero and the hop limit (TTL) field in the IPv6 >>>> header is set to zero.") >> >> It's probably not the best design but it's an asthetic issue, cjdns weeds the control packets >> out of the stream en route, it doesn't "bind to port 0". > > this isn't an aesthetic issue: you haven't decoupled your transport > protocol from the underlying carrier protocol. I.e. native cjdns is not > possible according to your current design. Not the underlying protocol, the overlay protocol. Cjdns control messages are basically a bastardized form of an ipv6 packet. On the outside anything that carries frames is ok. There's an module which links nodes over raw Ethernet and I'm told it works well. > >>>> >>>> - that strictly symmetric routing is a bug, not a feature >> >> Good to hear that cjdns isn't missing a feature. >> >>>> >>>> - that 64 bits as a routing path mechanism is woefully insufficient for >>>> modern networking >> >> /me snickers at the fact that it was said on an IPv6 mailing list. > > i think you misunderstand what I'm saying here. I'm not talking about 64 > bits of addressing space (which is more than enough to handle global > addressing requirements); i'm talking about 64 bits as a routing mechanism, > which will break on even relatively small networks. My mistake, indeed 64 is not a lot but as I said, we can expand by stacking with minimal protocol changes. > >>>> - that separation of control plane and data plane on a router is probably a >>>> good idea >> >> If you mean what I think you mean, that's already done ("cjdns weeds the packets out of >> the stream"). > > no it's not. you propose a remote forwarding lookup mechanism which mixes > up the forwarding plane of your routers (i.e. the mechanism which handles > traffic going _through_ the router) with the control plane (i.e. the > mechanism which handles traffic going _to_ the router). > > the idea of remote lookups for your forwarding mechanism is also > fundamentally broken because if there is one thing you need, it's a fast LISP ;) > forwarding lookup engine. this is one of the things which makes commercial > routers expensive: you need to be deterministic and fast about making > decisions on which interface to send your packet to, which means that it > needs to be local to the box making the decision. if you decouple these > two things, you're on a road to nowhere. Sending a DHT query and waiting a roundtrip to decide where to forward would be insane. Instead of sending a DHT query to a node, cjdns sends them the packet. Obviously it favors nodes which are physically nearby. What concerns me is if you had 1 billion nodes and the average node had a routing table with 500 physically close nodes and 500 numerically close.. You would need 2 million "nearby" nodes, otherwise your packets are going to travel a long way before reaching a node which knows a full route to the destination. However, if you only have 200k prefixes to forward to, this same partitioning trick might come in handy for forwarding ip4 on multicore commodity processors. > >>>> - throwing out the book on existing networking models is only valid if the >>>> proposed replacement is measurably better >> >> Bullshit. >> >> Throwing out the book is always valid, at best you invent the next big thing, at worst >> you have a great learning experience. In the middle, the good ideas are integrated into >> existing technologies and the bad ideas serve as a case study. > > green-field designs are fine from a research point of view, except that for > some reason which is entirely unclear to me, eugen was proposing cjdns as a > potential replacement for ipv4 / ipv6. throwing out ipv4 / ipv6 is only > valid if the proposed replacement is measurably better than them, which > cjdns isn't. Time will tell. > >>>> What's left in cjdns is a poorly specified mishmash of curious ideas which >>>> will work fine on the author's playpen network and which will break >>>> horribly on large networks, regardless of how hard the author waves the >>>> "hey look at me, i'm having a revolution" flag. >> >> If I was in charge of a major AS, I wouldn't implement *anything* which was developed >> with an R&D budget of 0. There are some potentially interesting components but as a whole, >> cjdns is not intended to work on large networks. >> >> In places like where I live, it's not cost effective for cable and phone companies to >> provide fast internet. >> >> I believe that people are willing to spend money on a pole and a few directional radio >> links if they can install the equipment and it will just work. I also think they'll be willing >> to share the data downstream if they can get a discount on their bill for the data they shared. > > speaking as someone who owns a rural house with this exact form of > connectivity problem, i'm not getting why ipv6 + igp + bgp + nat64 wouldn't > be a better solution for what you're proposing here - but even still, why > is this better from having a local ISP with public ipv4 / ipv6 addresses > and not depending on nat / protocol translation at all? i don't get it. The switch layer will happily carry any kind of traffic you like, including IPv4 packets so natting is unnecessary, you just pop the switch header and decrypt. Ever since the end of dialup I haven't seen a single new local ISP and I would never try it myself. The only way I see telephone/cable losing their control is if we can provide people with a kit ISP that anyone can setup. > > also, don't confuse transport speed and transport protocol. the two are > completely different. > >> What I need is a way to separate infrastructure, billing, and IP4 gateway provision. >> I want to put up a pole, make a directional radio link to my neighbor, sign up with a billing >> provider that takes major credit cards, and be online. I don't want to worry about my neighbor >> spying on my traffic and if someone links to my pole, I want a discount for carrying their bits. > > the cjdns-ipv4 (or ipv6->ipv4, e.g. nat64) translation router will offer > ample opportunities for spying if you're concerned about this. personally, The problem is if someone wants to compromise you, it's hard for them to infiltrate your IPv4 gateway provider but it's easy for them to set up a node in the network and begin carrying your traffic. > i use higher layer transport security where possible because you cannot in > general be guaranteed about anything relating to the underlying transport > mechanism. > >> IMO the most important role of cjdns is not in offering an answer but in introducing a question. > > yep, certainly does that. interesting design, but it won't work on > anything other than very small networks, and it doesn't offer any material > advantages over e.g. ipv6 + (ospf / isis) + bgp + nat64, which is already > standardised to the point that it will work using off the shelf components > with stock windows / linux / mac end user boxes. This is my solution, I realize it's not the only one and I'd love to see some competition in the field. My 3 main requirements are: * No single point of failure. * Anyone can start a node with little to no technical skill. * It must not be fruitful to start a node with the intention of committing Espionage/Forgery against a given target. Of course DoS should difficult. Again I appreciate your comments and right now I'm adding to my TODO list: - Stacking of switch headers. - Provable algorithms or at least simulations. Thanks, Caleb > > nick > > > ----- 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