From decapita at sansone.crema.unimi.it Fri Aug 1 09:27:02 2003 From: decapita at sansone.crema.unimi.it (Sabrina De Capitani di Vimercati) Date: Sat Dec 9 22:12:21 2006 Subject: [p2p-hackers] REMINDER: 2nd IEEE International Security in Storage Workshop Message-ID: [Apologies if you receive multiple copies of this message] CALL FOR PAPERS 2ND IEEE INTERNATIONAL SECURITY IN STORAGE WORKSHOP Washington, DC, USA - October 31, 2003 Sponsored by the IEEE Computer Society Task Force on Information Assurance http://www.stortek.com/hughes/sisw2003 ------------------------------------------------------------------------ The ability to create large shared storage systems in a secure manner is an area that has received little formal research or results. A comprehensive, systems approach to storage security is required if storage consolidation is to succeed. This workshop serves as an open forum to discuss storage threats, technologies, methodologies and deployment. The workshop seeks submissions from academia and industry presenting novel research on all theoretical and practical aspects of designing, building and managing secure storage systems; possible topics include, but are not limited to the following: - Cryptographic Algorithms for Storage - Key Management for Storage - Key Management for File Systems - Attacks on Storage Area Networks and Storage - Security for Mobile Storage - Defining and Defending Trust Boundaries in Storage - Relating Storage Security to Network Security - Cryptanalysis of Systems and Protocols - Novel Implementations - Unintended Data Recovery - Insider Attack Countermeasures - Deployment of Secure Storage Mechanisms - Security in Federated Systems - Security for Internet Storage Service Providers The goal of the workshop is to disseminate new research, and to bring together researchers and practitioners from both governmental and civilian areas. Accepted papers will be published by IEEE Press in the workshop s post-proceedings. SUBMISSIONS Papers must list all authors and affiliations, begin with a title, a short abstract, a list of key words, and an introduction. The introduction should summarize the contributions of the paper at a level appropriate for a non-specialist reader. Papers may be submitted in PostScript, PDF, HTML, or Microsoft Word. Papers should be at most 15 pages in length including the bibliography, figures, and appendices (using 10pt body text and two-column layout). Authors are responsible for obtaining appropriate clearances. Authors of accepted papers will be asked to sign IEEE copyright release forms. Final submissions must be in camera-ready PostScript or PDF. Authors of accepted papers must guarantee that their paper will be presented at the conference. Papers that duplicate work that any of the authors have or will publish elsewhere are acceptable for presentation at the workshop. However, only original papers will be considered for publication in the proceedings. PROGRAM CO-CHAIRS James Hughes Jack Cole StorageTek, USA US Army Research Laboratory, USA IMPORTANT DATES Paper due: August 11, 2003 Notification of acceptance: September 20, 2003 Workshop paper due: October 13, 2003 Workshop: October 31, 2003 Proceedings paper due: November 17, 2003 PROGRAM COMMITTEE Donald Beaver, Seagate, USA Randal Burns, Johns Hopkins University, USA Yongdae Kim, University of Minnesota, USA Ben Kobler, NASA Goddard, USA Fabio Maino, Andiamo Systems, USA Ethan Miller, UC Santa Cruz, USA David McGrew, Cisco Systems, USA Andrew Odlyzko, University of Minnesota, USA Jean-Jacques Quisquater, UCL, Belgium Pierangela Samarati, University of Milan, Italy Rodney Van Meter, Keio University, Japan Submissions and questions should be sent electronically to James Hughes < James_Hughes@StorageTek.com > From chris at openex.com Tue Aug 5 08:55:05 2003 From: chris at openex.com (chris) Date: Sat Dec 9 22:12:21 2006 Subject: [p2p-hackers] (no subject) Message-ID: Assume NATed client A,B and Server S If A and B send a udp packet to S, there should be a NAT mapping entry. Question: Would these mapping time out? Would NAT, after a period of inactivity, delete the A **S mapping entry? If so, assume A can keep this mapping alive by sending udp packets to S, so that S or other peer (e.g B) would be able to reach A If A doesn¡¯t want to put too much burden on S, can A send the packet just a few hops short of actually reaching S ? A¡¯s NAT box might receive a ICMP port unreachable packet, would it delete the mapping entry? Thanx. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20030805/32350678/attachment.htm From pfh at mail.csse.monash.edu.au Wed Aug 6 22:59:04 2003 From: pfh at mail.csse.monash.edu.au (Paul Harrison) Date: Sat Dec 9 22:12:21 2006 Subject: [p2p-hackers] UDP + NAT = blithering insanity In-Reply-To: Message-ID: On Tue, 5 Aug 2003, chris wrote: > Assume NATed client A,B and Server S > If A and B send a udp packet to S, there should be a NAT mapping entry. > > Question: > Would these mapping time out? Would NAT, after a period of inactivity, > delete the A **S mapping entry? Yes. > If so, assume A can keep this mapping alive by sending udp packets to S, = so > that S or other peer (e.g B) would be able to reach A If it's a paranoid NAT network, it might only let in packets from S. > If A doesn=A1=AFt want to put too much burden on S, can A send the packet= just a > few hops short of actually reaching S ? > A=A1=AFs NAT box might receive a ICMP port unreachable packet, would it d= elete > the mapping entry? > Only on Tuesdays. Seriously, this way lies madness. If you're using UDP through NAT you can only assume that it handles a single request/reply exchange, anything more will differ wildly between NAT implementations. I tried something like this with the Circle. It sometimes appears to work, then people randomly silently drop off the network or are only visible from nodes that they've directly contacted. The Circle solution is currently to run a small proxy on the NAT server (via ssh) and do all UDP from the server -- but this assumes the server has ssh and a unix-like environment (or whatever). The best solution is probably to just use TCP connections and do all your routing on top of that. cheers, Paul Email: pfh@logarithmic.net IM: pfh on thecircle.org.au Show me the WMD! From decapita at dti.unimi.it Sat Aug 9 05:34:04 2003 From: decapita at dti.unimi.it (Sabrina De Capitani di Vimercati) Date: Sat Dec 9 22:12:21 2006 Subject: [p2p-hackers] LAST REMINDER: 2nd IEEE International Security in Storage Workshop Message-ID: [Apologies if you receive multiple copies of this message] CALL FOR PAPERS 2ND IEEE INTERNATIONAL SECURITY IN STORAGE WORKSHOP Washington, DC, USA - October 31, 2003 Sponsored by the IEEE Computer Society Task Force on Information Assurance http://ieeeia.org/sisw2003/ ------------------------------------------------------------------------ The ability to create large shared storage systems in a secure manner is an area that has received little formal research or results. A comprehensive, systems approach to storage security is required if storage consolidation is to succeed. This workshop serves as an open forum to discuss storage threats, technologies, methodologies and deployment. The workshop seeks submissions from academia and industry presenting novel research on all theoretical and practical aspects of designing, building and managing secure storage systems; possible topics include, but are not limited to the following: - Cryptographic Algorithms for Storage - Key Management for Storage - Key Management for File Systems - Attacks on Storage Area Networks and Storage - Security for Mobile Storage - Defining and Defending Trust Boundaries in Storage - Relating Storage Security to Network Security - Cryptanalysis of Systems and Protocols - Novel Implementations - Unintended Data Recovery - Insider Attack Countermeasures - Deployment of Secure Storage Mechanisms - Security in Federated Systems - Security for Internet Storage Service Providers The goal of the workshop is to disseminate new research, and to bring together researchers and practitioners from both governmental and civilian areas. Accepted papers will be published by IEEE Press in the workshop s post-proceedings. SUBMISSIONS Papers must list all authors and affiliations, begin with a title, a short abstract, a list of key words, and an introduction. The introduction should summarize the contributions of the paper at a level appropriate for a non-specialist reader. Papers may be submitted in PostScript, PDF, HTML, or Microsoft Word. Papers should be at most 15 pages in length including the bibliography, figures, and appendices (using 10pt body text and two-column layout). Authors are responsible for obtaining appropriate clearances. Authors of accepted papers will be asked to sign IEEE copyright release forms. Final submissions must be in camera-ready PostScript or PDF. Authors of accepted papers must guarantee that their paper will be presented at the conference. Papers that duplicate work that any of the authors have or will publish elsewhere are acceptable for presentation at the workshop. However, only original papers will be considered for publication in the proceedings. PROGRAM CO-CHAIRS James Hughes Jack Cole StorageTek, USA US Army Research Laboratory, USA IMPORTANT DATES Paper due: August 11, 2003 Notification of acceptance: September 20, 2003 Workshop paper due: October 13, 2003 Workshop: October 31, 2003 Proceedings paper due: November 17, 2003 PROGRAM COMMITTEE Donald Beaver, Seagate, USA Randal Burns, Johns Hopkins University, USA Yongdae Kim, University of Minnesota, USA Ben Kobler, NASA Goddard, USA Fabio Maino, Andiamo Systems, USA Ethan Miller, UC Santa Cruz, USA David McGrew, Cisco Systems, USA Andrew Odlyzko, University of Minnesota, USA Jean-Jacques Quisquater, UCL, Belgium Pierangela Samarati, University of Milan, Italy Rodney Van Meter, Keio University, Japan Submissions and questions should be sent electronically to James Hughes < James_Hughes@StorageTek.com > From decapita at dti.unimi.it Thu Aug 14 11:09:02 2003 From: decapita at dti.unimi.it (Sabrina De Capitani di Vimercati) Date: Sat Dec 9 22:12:21 2006 Subject: [p2p-hackers] Call for Partecipation: 8th European Symposium on Research in Computer Security (ESORICS'03) Message-ID: [Apologies if you receive multiple copies of this message] CALL FOR PARTECIPATION 8TH EUROPEAN SYMPOSIUM ON RESEARCH IN COMPUTER SECURITY Gj?vik, Norway - October 13-15, 2003 Organized by Gj?vik University College Held in conjunction with Nordsec 2003 http://www.hig.no/esorics2003/ ********************************************************************** DEADLINE FOR REGISTRATION: SEPTEMBER 15, 2003 ********************************************************************** AIMS AND SCOPE Organised in a series of European countries, ESORICS is confirmed as the European research event in computer security. The symposium started in 1990 and is now held every year in different European countries and attracts audience from both the academic and industrial communities. The Symposium has established itself as one of the premiere, international gatherings on Information Assurance. CONFERENCE VENUE Gj?vik is called "The White Town at Mj?sa" because of all the white houses up the hill from the lake. As you may understand, it's quite a small town. The number of inhabitants is 6000. Gj?vik town is the centre of a municipality, also called Gj?vik, and the number of inhabitants in the municipality is 26000. Gj?vik is lying on the shores of Mj?sa, the largest inland lake in Norway. Mj?sa is about 100 kilometres long, from south to north. On the north end, we find Lillehammer, where the 17th Winter Olympic Games took place in February 1994. We find Gj?vik midway between south and north end of the lake. FOR MORE INFORMATION For details: http://www.hig.no/esorics2003 On-site arrangements: esorics2003info@hig.no General program information: esorics2003prog@hig.no From decapita at sansone.crema.unimi.it Mon Aug 18 06:02:02 2003 From: decapita at sansone.crema.unimi.it (Sabrina De Capitani di Vimercati) Date: Sat Dec 9 22:12:21 2006 Subject: [p2p-hackers] CFP: SAC2004 - Track on Computer Security (3rd edition) Message-ID: [Apologies if you receive multiple copies of this message] CALL FOR PAPERS THE 19TH ACM SYMPOSIUM ON APPLIED COMPUTING (SAC 2004) Track on Computer Security (3rd edition) Nicosia, Cyprus - March 14-17, 2004 http://www.dmi.unict.it/~giamp/sac/ ---------------------------------------------------------------------- SAC 2004 For the past eighteen years the ACM Symposium on Applied Computing (SAC) has been a primary forum for applied computer scientists, computer engineers and application developers to gather, interact, and present their research. SAC is sponsored by the ACM Special Interest Group on Applied Computing (SIGAPP); its proceedings are published by ACM in both printed form and CD-ROM; they are also available on the web through the ACM Digital Library. More information about SIGAPP and past editions of SAC can be found at http://www.acm.org/sigapp 2004 TRACK ON COMPUTER SECURITY (3RD EDITION) The proliferation of network computing and especially the ubiquity of the Internet has made security one of the key areas in modern computing. The third edition of the Security Track strengthens its aims at bringing together researchers in any applied issues of computer and information security. These issues may vastly range from protocols to laws. Topics of interest include but are not limited to - software security (protocols, operating systems, etc.) - hardware security (smartcards, biometric technologies, etc.) - mobile security (properties for/from mobile agents, etc.) - network security (anti-virus, anti-hacker, anti-DoS tools, firewalls, real-time monitoring, etc.) - alternatives to cryptography (steganography, etc.) - security-specific software development practices (vulnerability testing, fault-injection resilience, etc.) - privacy and anonimity (trust management, pseudonimity, identity management, etc.) - safety and dependability issues (reliability, survivability, etc.) - cyberlaw and cybercrime (copyrights, trademarks, defamation, intellectual property, etc.) TRACK WEBSITE The 2004 edition of the Security Track is the third of a successfull series, whose details are available at http://www.dmi.unict.it/~giamp/sac PROGRAM CHAIRS Giampaolo BELLA Dipartimento di Matematica e Informatica - Universita' di Catania Viale A. Doria, 6 I-95125 Catania, (ITALY) Phone: +39 095 7383050 Fax: +39 095 330094 email: giamp@dmi.unict.it Peter RYAN School of Computing Science - University of Newcastle upon Tyne Newcastle upon Tyne, NE1 7RU, (UK) Phone: +44 191 2228972 Fax : +44 191 2228788 email: peter.ryan@newcastle.ac.uk PROGRAM COMMITTEE Gail-Joon Ahn (University of North Caroline at Charlotte, USA) Bruno Blanchet (Ecole Normale Superieure, France) Arslan Broemme (University of Magdeburg, Germany) Nancy Durgin (Sandia National Laboratories, USA) Simon Foley (University College, Cork, Ireland) Stefanos Gritzalis (University of the Aegean, Greece) Sokratis K Katsikas (University of the Aegean, Greece) Heiko Mantel (German Research Center for Artificial Intelligence, Germany) Pierangela Samarati (Universita' di Milano, Italy) Vitaly Shmatikov (SRI International, USA) SUBMISSION GUIDELINES The submission guidelines must be strictly followed for a paper to be considered. Original papers from the above mentioned or other related areas will be considered. Only full papers about original and unpublished research are sought. Parallel submission to other conferences or other tracks of SAC 2004 is forbidden. Each paper must be BLIND in the sense that it must only include its title but not mention anything about its authors. Self-reference should be blind too. Each paper will be fully refereed and undergo a blind review process by at least three referees. Authors of submitted papers may be required to participate in the review process as referees. The body of each paper should not exceed 5,000 words, that is approx. 14 pages using LaTeX "article" style, which is the preferred style for submission. Papers failing to comply with length limitations risk immediate rejection. All papers must be submitted by 6 September 2003. It is once more remarked that the author(s) name(s) and address(es) must not appear in the body (including self-references) of the submitted paper in order to allow blind review. Those details shall only be added later to accepted papers. Accepted papers shall be formatted according to the conference LaTeX style, which can be obtained from the symposium web page, and will be published in the ACM SAC 2004 proceedings. Some papers will be only accepted as poster papers, and will be published as extended 2-page abstracts in the proceedings. Anyone wishing to review papers for the Security Track should email either Program Chair. Submission is entirely mechanised by the CRP tool (Conference Review Package -- Copyright 2001 Univ. of Colorado). The submission page can be found here, where authors must first register their own account by obtaining a password, and then follow the instructions. ACKWNOWLEDGEMENTS Special thanks to Luigi Toscano (toscano@dmi.unict.it) and Giuseppe Patane' (patane@dmi.unict.it) for maintaining the installation of the CRP tool at Catania. IMPORTANT DATES 6 September 2003: Submission of papers 18 October 2003: Notification of Acceptance/Rejection 8 November 2003: Camera-Ready copies of accepted papers 14-17 March 2004: SAC 2004 takes place From hopper at omnifarious.org Tue Aug 19 21:02:01 2003 From: hopper at omnifarious.org (Eric M. Hopper) Date: Sat Dec 9 22:12:21 2006 Subject: [p2p-hackers] CAKE = Key Addressed Crypto Encapsulation Message-ID: <1061352085.30074.24.camel@monster.omnifarious.org> I have an idea that's been wandering around in my head for awhile, waiting to be clear enough to be worth implementing. The idea germinated in Zooko's paper on names, a system for doing name-based routing (http://www-dsg.stanford.edu/triad/) someone pointed out to me. Also, I was trying to design a fully distributed secure instant messaging system that could also do filesharing for http://www.hotim.com/ (now defunct). The basic idea is simple. Build a lowish level protocol that lives somewhere between IP and sockets that has every message being addressed to a public key. I've begun work on this, and have some preliminary documentation written. I've also sucessfully sent a few messages via SMTP. I'm in the process of writing code that will let you run CAKE through SMTP. Initially, I intend to start trying to slowly take over SMTP person-by-person, selling the security enhancement, location independence, and spam resistent qualities of the protocol. Now that a lot of my ideas have formed and taken a definite shape, I'm interested in feedback from a wider group. The implementation is currently written in a combination of C++ and Python. It requires Python, the GMP library, and Swig to work. What I have so far can be found at: https://svn.generalpresence.com:5131/repos/trunk/C++/pract_crypto/doc/index.html Thanks, -- There's an excellent C/C++/Python/Unix/Linux programmer with a wide range of other experience and system admin skills who needs work. Namely, me. http://www.omnifarious.org/~hopper/resume.html -- Eric Hopper -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 185 bytes Desc: This is a digitally signed message part Url : http://zgp.org/pipermail/p2p-hackers/attachments/20030819/21e46991/attachment.pgp From tyler at waterken.com Wed Aug 20 10:45:02 2003 From: tyler at waterken.com (Tyler Close) Date: Sat Dec 9 22:12:21 2006 Subject: [p2p-hackers] CAKE = Key Addressed Crypto Encapsulation In-Reply-To: <1061352085.30074.24.camel@monster.omnifarious.org> References: <1061352085.30074.24.camel@monster.omnifarious.org> Message-ID: On Wednesday 20 August 2003 00:01, Eric M. Hopper wrote: > The basic idea is simple. Build a lowish level protocol that lives > somewhere between IP and sockets that has every message being addressed > to a public key. This is also the basic idea behind YURLs. See: http://www.waterken.com/dev/YURL/ I've designed a YURL protocol for HTTP. See: http://www.waterken.com/dev/YURL/httpsy/ There are client and server implementations, as well as a simple WWW browser. You can use the browser to securely surf sites identified by their public key. No need for Verisign or IANA. > I've begun work on this, and have some preliminary documentation > written. I've also sucessfully sent a few messages via SMTP. I'm in > the process of writing code that will let you run CAKE through SMTP. > Initially, I intend to start trying to slowly take over SMTP > person-by-person, selling the security enhancement, location > independence, and spam resistent qualities of the protocol. Looking at the info at: https://svn.generalpresence.com:5131/repos/trunk/C++/pract_crypto/doc/message_000.html You seem to be creating your own transport encryption layer and application protocol layer, and just tunneling over SMTP. Why? I think you could get more leverage from reusing an existing crypto protocol and being compatible with an existing application protocol. I think something similar to what I have done for HTTP could also be done for SMTP. Any thoughts? Tyler -- The union of REST and capability-based security: http://www.waterken.com/dev/Web/ From hopper at omnifarious.org Wed Aug 20 11:39:01 2003 From: hopper at omnifarious.org (Eric M. Hopper) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] CAKE = Key Addressed Crypto Encapsulation In-Reply-To: References: <1061352085.30074.24.camel@monster.omnifarious.org> Message-ID: <1061404738.30074.47.camel@monster.omnifarious.org> On Wed, 2003-08-20 at 12:22, Tyler Close wrote: > You seem to be creating your own transport encryption layer and > application protocol layer, and just tunneling over SMTP. Why? I > think you could get more leverage from reusing an existing crypto > protocol and being compatible with an existing application > protocol. I think something similar to what I have done for HTTP > could also be done for SMTP. > > Any thoughts? Well, I thought about that, but it seems like everyone is inventing their own application layer for their own protocol to do exactly this. There's your YURL (which I noticed, but forgot to mention), there's SFS, and I suppose you could press OpenPGP into service for email. So, there exists of all of these things that all do something that's approximately the same at one level, then build an application layer on top of it. It seems to me they could all benefit from having a base layer that does things in this way. Lastly, there needs to be some standard way of getting information about keys, particularly ones that have expired. Your httpsy system doesn't seem to have any system for handling key expiration, and the release of a new key which supersedes an old key. This is handled in GPG by the relatively centralized mechanism of public key servers. But, it should be handled in a more distributed, DNS-like fashion. That's why I think a new layer that's lower than the application layer, but higher than IP is needed. Just imagine if you could write random networked applications and trust adresses to always refer to the same entity, and that every message that comes from an address really does come from that address. Have fun (if at all possible), -- There's an excellent C/C++/Python/Unix/Linux programmer with a wide range of other experience and system admin skills who needs work. Namely, me. http://www.omnifarious.org/~hopper/resume.html -- Eric Hopper -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 185 bytes Desc: This is a digitally signed message part Url : http://zgp.org/pipermail/p2p-hackers/attachments/20030820/2bc172df/attachment.pgp From hopper at omnifarious.org Wed Aug 20 13:00:02 2003 From: hopper at omnifarious.org (Eric M. Hopper) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] CAKE = Key Addressed Crypto Encapsulation In-Reply-To: References: <1061352085.30074.24.camel@monster.omnifarious.org> Message-ID: <1061409579.30074.65.camel@monster.omnifarious.org> On Wed, 2003-08-20 at 12:22, Tyler Close wrote: > You seem to be creating your own transport encryption layer and > application protocol layer, and just tunneling over SMTP. Why? I > think you could get more leverage from reusing an existing crypto > protocol and being compatible with an existing application > protocol. I think something similar to what I have done for HTTP > could also be done for SMTP. Oh, also, SMTP encapsulation is just a start. SMTP is like a very slow, but more reliable UDP. Message boundaries are preserved and delivery is, while not guaranteed, something a little more substantial than best effort. I also chose SMTP because I started from the perspective of messages intended for human consumption. Have fun (if at all possible), -- There's an excellent C/C++/Python/Unix/Linux programmer with a wide range of other experience and system admin skills who needs work. Namely, me. http://www.omnifarious.org/~hopper/resume.html -- Eric Hopper -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 185 bytes Desc: This is a digitally signed message part Url : http://zgp.org/pipermail/p2p-hackers/attachments/20030820/0f043a85/attachment.pgp From tyler at waterken.com Wed Aug 20 13:33:02 2003 From: tyler at waterken.com (Tyler Close) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] CAKE = Key Addressed Crypto Encapsulation In-Reply-To: <1061404738.30074.47.camel@monster.omnifarious.org> References: <1061352085.30074.24.camel@monster.omnifarious.org> <1061404738.30074.47.camel@monster.omnifarious.org> Message-ID: On Wednesday 20 August 2003 14:38, Eric M. Hopper wrote: > On Wed, 2003-08-20 at 12:22, Tyler Close wrote: > > You seem to be creating your own transport encryption layer and > > application protocol layer, and just tunneling over SMTP. Why? I > > think you could get more leverage from reusing an existing crypto > > protocol and being compatible with an existing application > > protocol. I think something similar to what I have done for HTTP > > could also be done for SMTP. > > > > Any thoughts? > > Well, I thought about that, but it seems like everyone is inventing > their own application layer for their own protocol to do exactly this. > There's your YURL (which I noticed, but forgot to mention), there's SFS, > and I suppose you could press OpenPGP into service for email. The HTTPSY protocol does not invent a new application layer, it reuses the HTTP application layer. This feature makes HTTPSY compatible with existing WWW software, like browsers and XSLT stylesheets. The Waterken(TM) Browser is just a normal WWW browser that has a protocol handler for httpsy installed. This browser would not be possible if HTTPSY was not compatible with HTTP. There isn't any existing software that is compatible with your proposed protocol. Given that you have unlimited design freedom at this point, this lack of interoperability seems like a poor choice. > So, there exists of all of these things that all do something that's > approximately the same at one level, then build an application layer on > top of it. It seems to me they could all benefit from having a base > layer that does things in this way. So which layer of the HTTPSY protocol would you propose changing: TLS/1.0, HTTP? > Lastly, there needs to be some standard way of getting information about > keys, particularly ones that have expired. Your httpsy system doesn't > seem to have any system for handling key expiration, and the release of > a new key which supersedes an old key. Sure it does. HTTPSY reuses the existing X.509 mechanism for key replacement. This is actually a FAQ. See: http://www.waterken.com/dev/YURL/FAQ/#key_replacement_a > This is handled in GPG by the > relatively centralized mechanism of public key servers. But, it should > be handled in a more distributed, DNS-like fashion. The YURL mechanism is as decentralized as is possible. Each site has full control over its key lifetimes. > That's why I think a new layer that's lower than the application layer, > but higher than IP is needed. Just imagine if you could write random > networked applications and trust adresses to always refer to the same > entity, and that every message that comes from an address really does > come from that address. An httpsy:// URL meets that promise for the HTTP world. Tyler -- The union of REST and capability-based security: http://www.waterken.com/dev/Web/ From hopper at omnifarious.org Wed Aug 20 14:40:01 2003 From: hopper at omnifarious.org (Eric M. Hopper) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] CAKE = Key Addressed Crypto Encapsulation In-Reply-To: References: <1061352085.30074.24.camel@monster.omnifarious.org> <1061404738.30074.47.camel@monster.omnifarious.org> Message-ID: <1061415568.30074.141.camel@monster.omnifarious.org> On Wed, 2003-08-20 at 15:10, Tyler Close wrote: > On Wednesday 20 August 2003 14:38, Eric M. Hopper wrote: > > On Wed, 2003-08-20 at 12:22, Tyler Close wrote: > > > You seem to be creating your own transport encryption layer and > > > application protocol layer, and just tunneling over SMTP. Why? I > > > think you could get more leverage from reusing an existing crypto > > > protocol and being compatible with an existing application > > > protocol. I think something similar to what I have done for HTTP > > > could also be done for SMTP. > > > > > > Any thoughts? > > > > Well, I thought about that, but it seems like everyone is inventing > > their own application layer for their own protocol to do exactly this. > > There's your YURL (which I noticed, but forgot to mention), there's SFS, > > and I suppose you could press OpenPGP into service for email. > > The HTTPSY protocol does not invent a new application layer, it > reuses the HTTP application layer. This feature makes HTTPSY > compatible with existing WWW software, like browsers and XSLT > stylesheets. The Waterken(TM) Browser is just a normal WWW browser > that has a protocol handler for httpsy installed. This browser > would not be possible if HTTPSY was not compatible with HTTP. OK then, you are creating a new https layer that is pk-identity based, but doesn't really leave behind the baggage of DNS or IP. Can your protocol handle a webserver that's on a dynamic IP if the person doesn't have a complicated dynamic DNS setup? What happens if the server's IP changes while someone is browsing it? > There isn't any existing software that is compatible with your > proposed protocol. Given that you have unlimited design freedom at > this point, this lack of interoperability seems like a poor > choice. I've been looking at a good way to add a new URL type to Mozilla. It isn't hard. There needs to be at least two new URL types. First, a new URL type for dynamic content and pk-identity based addresses. And a URI for static content so it can be retrieved via some distributed cache system like freenet. > So which layer of the HTTPSY protocol would you propose changing: > TLS/1.0, HTTP? Both, TLS/1.0 is based on X.509 certificates which are painfully obscure and badly designed. ASN.1 is not for the feint of heart, and the whole 'ou', 'cn', 'dn' thing makes no sense to people who work in organizations of less than 500 people, doesn't fit the rest of the Internet, and was obviously designed by committee of technical bureaucrats. TLS itself has several problems. First, it is based on the idea that the primary thing you want to connect to is an IP address and port #, not the owner of a pk-identity. httpsy is largely an attempt to remove this defficiency from TLS. TLS is also a hodegpodge of various encryption techniques that make its implementation quite complicated. Some of these exist only as a legacy of stupid US export control legislation and some (like any RC4 based scheme) are simply gratuitous at this point. HTTP requires the creation of a full session to retrieve a small amount of static content when in truth, most HTTP requests could be stuffed into a UDP packet. It also has poor cache semantics and newer versions have become incredibly bloated with extensions designed to graft a filesystem on top of it. HTTP could be implemented on top of CAKE with no change to Apache by simply having a simple local proxy that unwrapped the CAKE messages and translated them into HTTP requests. The proxy could even stuff the pk-identity of the requestor into a cookie, thereby eliminating the need for session cookies. The data inside an individual CAKE HTTP request would actually look a lot like an HTTP/1.0 request currently does. Small requests could live inside a UDP packet instead of requiring the initiation of a TCP session before you could send a request. Of course, then you leave yourself a little more open for DOS attacks, so that might have to be thought through more carefully. And, since CAKE messages leave the source, destination, and message type out in the open, they can be firewalled with very fine granularity, especially since the source can be verified to be correct by the firewall. > Sure it does. HTTPSY reuses the existing X.509 mechanism for key > replacement. This is actually a FAQ. See: > > http://www.waterken.com/dev/YURL/FAQ/#key_replacement_a That isn't sufficient. Public keys wear out for more reasons than use. Making sure the private key is only used to sign other public keys will keep it alive longer, but it won't keep it alive forever. What would work is if every key were a 'CA' key, and you used the old key to sign the new key when the old key expired. From an X.509 standpoint that would be very strange of course. > The YURL mechanism is as decentralized as is possible. Each site > has full control over its key lifetimes. Yes, aside from many browsers complaining about keys not being signed by a magic CA, your scheme is fully decentralized. > > That's why I think a new layer that's lower than the application layer, > > but higher than IP is needed. Just imagine if you could write random > > networked applications and trust adresses to always refer to the same > > entity, and that every message that comes from an address really does > > come from that address. > > An httpsy:// URL meets that promise for the HTTP world. First, it doesn't. It provides excellent verification of the server identity. The y-property is really the best you can hope for in the absence of some globally mandated trusted authority. But, it provides no verification of the client to the server. Client-side certificates are exceedingly rare. Even then, though it solves a problem for HTTP, what solves it for SMTP, NFS, DNS, or anything else? All of these need something, and httpsy is for URLs, and URLs are largely for browsers. Browsers are not the be all and end all of applications on the Internet. Have fun (if at all possible), -- There's an excellent C/C++/Python/Unix/Linux programmer with a wide range of other experience and system admin skills who needs work. Namely, me. http://www.omnifarious.org/~hopper/resume.html -- Eric Hopper -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 185 bytes Desc: This is a digitally signed message part Url : http://zgp.org/pipermail/p2p-hackers/attachments/20030820/cfb9df9a/attachment.pgp From ingo at fargonauten.de Thu Aug 21 02:25:01 2003 From: ingo at fargonauten.de (ingo@fargonauten.de) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] CAKE = Key Addressed Crypto Encapsulation In-Reply-To: <1061415568.30074.141.camel@monster.omnifarious.org> References: <1061352085.30074.24.camel@monster.omnifarious.org> <1061404738.30074.47.camel@monster.omnifarious.org> <1061415568.30074.141.camel@monster.omnifarious.org> Message-ID: <20030821092003.GA28645@fargonauten.de> Hi Eric, it might be pointed out that TLS doesn't require X.509. Thats just the default. X.509 has its drawbacks but its still the only mature format out there. Specs for use of TLS with e.g. OpenPGP exist and are implemented. However, your mentioning of UDP as a transport makes me wonder: What kind of usage model do you have in mind for CAKE that you would want to bother with a connectionless transport? bye -- http://fargonauten.de/ingo Perl: There's more than one way to do it Python: There should be one reasonable way to do it From hopper at omnifarious.org Thu Aug 21 06:35:02 2003 From: hopper at omnifarious.org (Eric M. Hopper) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] CAKE = Key Addressed Crypto Encapsulation In-Reply-To: <20030821092003.GA28645@fargonauten.de> References: <1061352085.30074.24.camel@monster.omnifarious.org> <1061404738.30074.47.camel@monster.omnifarious.org> <1061415568.30074.141.camel@monster.omnifarious.org> <20030821092003.GA28645@fargonauten.de> Message-ID: <1061472846.30074.206.camel@monster.omnifarious.org> On Thu, 2003-08-21 at 04:20, ingo@fargonauten.de wrote: > Hi Eric, > > it might be pointed out that TLS doesn't require X.509. Thats just > the default. X.509 has its drawbacks but its still the only mature > format out there. Specs for use of TLS with e.g. OpenPGP exist and > are implemented. That's interesting to know. I wasn't aware this was the case. I thought it was possible, but didn't know it had been done. TLS still has the other disadvantages I mentioned. > However, your mentioning of UDP as a transport makes me wonder: What > kind of usage model do you have in mind for CAKE that you would want > to bother with a connectionless transport? Sessions require a lot of shared state between parties. They also often require the parties be able to communicate within certain latency and bandwidth constraints. For example, one reason people use email to communicate instead of IM is that they can send a message to someone who isn't even connected to the network at the time. CAKE supports 4 main message types. One of these message types is for messages that aren't part of a session. They are 'bolt from the blue' type messages, much like UDP or email. They don't have an associated session, and assume the only shared state between the two parties is their public keys. This means that (as a concious design decision on my part) CAKE non-session messages have no built in protection against replay attacks, though there is protection against forged source addresses. So the only replay attack you could do is capture a message sent and send it again, though it would still look like it came from the original source. The other types are nonsession multicast, global assertion, and session setup & maintenance. Have fun (if at all possible), -- There's an excellent C/C++/Python/Unix/Linux programmer with a wide range of other experience and system admin skills who needs work. Namely, me. http://www.omnifarious.org/~hopper/resume.html -- Eric Hopper -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 185 bytes Desc: This is a digitally signed message part Url : http://zgp.org/pipermail/p2p-hackers/attachments/20030821/60cc0e76/attachment.pgp From baford at mit.edu Thu Aug 21 09:35:02 2003 From: baford at mit.edu (Bryan Ford) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] Re: CAKE = Key Addressed Crypto Encapsulation (Eric M. Hopper) In-Reply-To: <20030820102922.22120.33863.Mailman@capsicum.zgp.org> References: <20030820102922.22120.33863.Mailman@capsicum.zgp.org> Message-ID: <200308211234.32785.baford@mit.edu> Eric wrote: > I have an idea that's been wandering around in my head for awhile, [...] > > The basic idea is simple. Build a lowish level protocol that lives > somewhere between IP and sockets that has every message being addressed > to a public key. >[...] Sounds very closely related, at least in terms of basic goals, to something I've been working on for a little while too. We should compare notes. Basically, I'm also trying to create a new protocol between IP and sockets that provides secure end-to-end communication using cryptographic node identities rather than topology-sensitive addresses. But the protocol I'm developing can also serve as a "real" network-layer routing protocol as well, operating both within and beyond the scope of IP to provide seemless reachability across non-IP-based ad hoc wireless networks and such in addition to the traditional "wired" Internet. I'm tentatively calling it "Unmanaged Internet Protocol" (UIP); a brief description in the form of a position paper is available here: http://www.brynosaurus.com/pub/os/uip-case.pdf I also have a prototype implementation underway but not yet functional; in the interest of openness I'm keeping the source code and other preliminary nodes on sourceforge, though don't expect to see anything particularly interesting or comprehensible there just yet... :) http://sourceforge.net/projects/uip From tyler at waterken.com Thu Aug 21 12:33:02 2003 From: tyler at waterken.com (Tyler Close) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] CAKE = Key Addressed Crypto Encapsulation In-Reply-To: <1061415568.30074.141.camel@monster.omnifarious.org> References: <1061352085.30074.24.camel@monster.omnifarious.org> <1061415568.30074.141.camel@monster.omnifarious.org> Message-ID: You make a number of points in this email that I wish to respond to. I have separated them out and responded to the most important ones first. On Wednesday 20 August 2003 17:39, Eric M. Hopper wrote: > The y-property is really the best you can hope for in the > absence of some globally mandated trusted authority. The y-property is not a tradeoff, it is the definition of the optimal authority distribution in an introduction. Even if there were such a thing as a globally mandated trusted authority, there is nothing it could do to improve upon the y-property. For example, Verisign is a close approximation to a "globally mandated trusted authority". An introduction implemented using the Verisign CA is strictly *less* secure that an introduction implemented using a YURL. In a YURL introduction, *only* the introducer has the authority to determine the message target. In a PKI introduction, *both* the introducer and the CA have the authority to determine the message target. The PKI introduction has a wider distribution of authority, violating the principle of least priviledge. > But, it provides no verification of the client to the server. You are correct, the y-property says nothing on the topic of client authentication. Client authentication is used to implement access control in an ACL model. The y-property keeps access control distinct from authentication. Client authentication can be implemented orthogonally to the y-property. This leaves open the choice of an access control model. Note that your protocol does not leave this choice open. By bundling client authentication with server authentication, you have implicitly chosen an ACL-based access control model. Your protocol is unsuitable for a capability-based access control model. The capability-based access control model depends on the identity of the client not being significant. Forcing the client to provide an identity breaks capability-based messaging. > Even then, though it solves a problem for HTTP, what solves it for SMTP, > NFS, DNS, or anything else? All of these need something, and httpsy is > for URLs, and URLs are largely for browsers. First, let's eliminate DNS. DNS does not provide introduction functionality, it just maps a string to location information, not a communication channel. DNS is more like a YURL redirection service. Yes, each application protocol needs 'something' to enforce the y-property in its introductions. You can add this 'something' by defining a new protocol and building a proxy server for each existing application protocol, or by extending the existing application protocol. I submit that extending the existing application protocol makes better use of existing resources, and is the path of least resistance. For example, HTTPSY implements the y-property by reusing TLS/1.0 and extending the HTTP protocol. Very little specification and implementation work needed to be done to implement the y-property. Your task with CAKE is considerably more daunting. Realize that the implementation work is only a small part of the task of deploying a new protocol. The evangelising work is the toughest part. I think you underestimate the task ahead of you with CAKE. There are those in the cryptography community that believe that any new TCP/IP based protocol that does not use TLS is snake-oil. By creating a new encryption protocol, you are competing head-on with TLS and its supporters. I sympathize with your complaints about the baroque nature of TLS, but the fact is the protocol is widely studied and supported, and widely implemented in software and hardware. TLS is useable for implementing the y-property, so from a pragmatic point of view, using TLS is the right thing to do. Given that you have already recognized the need to interact with existing HTTP-based software, there is no way for you to escape the baroque nature of HTTP. Given that you have to accept HTTP, you might as well get as much out of it as you can. Anything you add, just makes the end product that much more baroque. We've never met, so you don't have any idea how much I sympathize with your desire for a simpler protocol. Those who do know me can no doubt guess how hard it was for me to design HTTPSY. That said, HTTPSY is the right design for bringing the y-property to HTTP applications. It gets the job done and is minimally disruptive. I think this same approach is the right one for other application protocols. > > Sure it does. HTTPSY reuses the existing X.509 mechanism for key > > replacement. This is actually a FAQ. See: > > > > http://www.waterken.com/dev/YURL/FAQ/#key_replacement_a > > That isn't sufficient. Public keys wear out for more reasons than use. Have you carefully studied the reasons, and the attacks to be thwarted? Do you have a link? > Making sure the private key is only used to sign other public keys will > keep it alive longer, but it won't keep it alive forever. It doesn't have to stay alive forever. The key only has to last as long as the resource it is authenticating. Given that a CA key is conservatively valid for 30+ years, you'll have a tough time showing this isn't sufficient for a WWW resource. Has there ever been an active-computing agent that has lived longer than 30 years? > What would work is if every key were a 'CA' key, and you used > the old key to sign the new key when the old key expired. From > an X.509 standpoint that would be very strange of course. You don't need this cryptographic technique. It is enough for the old resource to introduce the client to the new resource, using a normal introduction. From a cryptographic viewpoint, this is like using the old key to send an authenticated message containing the new key. Instead of a new signing protocol, you use the existing authentication protocol. > OK then, you are creating a new https layer that is pk-identity based, > but doesn't really leave behind the baggage of DNS or IP. The HTTPSY protocol can be used as a replacement for DNS. See the definition of the httpsy URL scheme: http://www.waterken.com/dev/YURL/httpsy/#The_httpsy_scheme I don't see how any of us can escape IP. > but doesn't really leave behind the baggage of DNS or IP. Can your > protocol handle a webserver that's on a dynamic IP if the person doesn't > have a complicated dynamic DNS setup? What happens if the server's IP > changes while someone is browsing it? Sure, as much as any use of HTTP can. Changing the IP address would break the TCP/IP connection. The client would try to reconnect by getting a new address from the redirection service identified in the httpsy URL. The server would update the redirection service with its new IP address. The redirection service is the server identified by the 'host' in the httpsy URL. > I've been looking at a good way to add a new URL type to Mozilla. It > isn't hard. I also need to do this for the httpsy protocol. I'd appreciate it if you could post information on how to do this. > Small requests could live inside a UDP packet instead of requiring the > initiation of a TCP session before you could send a request. Of course, > then you leave yourself a little more open for DOS attacks, so that > might have to be thought through more carefully. You'll still have to open a TCP session to get the response back. The response won't fit in a UDP packet. > Of course, > then you leave yourself a little more open for DOS attacks, so that > might have to be thought through more carefully. Interesting, can you explain or provide links? I have also been working on a UDP protocol that implements the y-property, but for different reasons. I'll announce it here when the spec is ready. Perhaps there will be a collaboration opportunity. Tyler -- The union of REST and capability-based security: http://www.waterken.com/dev/Web/ From hopper at omnifarious.org Thu Aug 21 21:13:02 2003 From: hopper at omnifarious.org (Eric M. Hopper) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] Re: CAKE = Key Addressed Crypto Encapsulation (Eric M. Hopper) In-Reply-To: <200308211234.32785.baford@mit.edu> References: <20030820102922.22120.33863.Mailman@capsicum.zgp.org> <200308211234.32785.baford@mit.edu> Message-ID: <1061525560.30074.217.camel@monster.omnifarious.org> On Thu, 2003-08-21 at 11:34, Bryan Ford wrote: > Eric wrote: > > I have an idea that's been wandering around in my head for awhile, [...] > > > > The basic idea is simple. Build a lowish level protocol that lives > > somewhere between IP and sockets that has every message being addressed > > to a public key. > >[...] > > Sounds very closely related, at least in terms of basic goals, to something > I've been working on for a little while too. We should compare notes. Yeah, reading your paper, the basic ideas look identical. I started working on this in late June. :-) I need to read your paper more thoroughly, but it sounds like we have a lot to talk about. Have fun (if at all possible), -- There's an excellent C/C++/Python/Unix/Linux programmer with a wide range of other experience and system admin skills who needs work. Namely, me. http://www.omnifarious.org/~hopper/resume.html -- Eric Hopper -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 185 bytes Desc: This is a digitally signed message part Url : http://zgp.org/pipermail/p2p-hackers/attachments/20030821/60481e6b/attachment.pgp From hopper at omnifarious.org Fri Aug 22 08:27:02 2003 From: hopper at omnifarious.org (Eric M. Hopper) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] CAKE = Key Addressed Crypto Encapsulation In-Reply-To: References: <1061352085.30074.24.camel@monster.omnifarious.org> <1061415568.30074.141.camel@monster.omnifarious.org> Message-ID: <1061565982.30074.272.camel@monster.omnifarious.org> On Thu, 2003-08-21 at 14:09, Tyler Close wrote: > You make a number of points in this email that I wish to respond > to. I have separated them out and responded to the most important > ones first. > > On Wednesday 20 August 2003 17:39, Eric M. Hopper wrote: > > The y-property is really the best you can hope for in the > > absence of some globally mandated trusted authority. > > The y-property is not a tradeoff, it is the definition of the > optimal authority distribution in an introduction. Even if there > were such a thing as a globally mandated trusted authority, there > is nothing it could do to improve upon the y-property. Yes, I agree with you. I think the CA system is actually less trustworthy, and I meant 'globally mandated trusted authority' in a rather dryly sarcastic vein. :-) > You are correct, the y-property says nothing on the topic of > client authentication. Client authentication is used to implement > access control in an ACL model. The y-property keeps access > control distinct from authentication. Client authentication can be > implemented orthogonally to the y-property. This leaves open the > choice of an access control model. > > Note that your protocol does not leave this choice open. By > bundling client authentication with server authentication, you > have implicitly chosen an ACL-based access control model. Your > protocol is unsuitable for a capability-based access control > model. The capability-based access control model depends on the > identity of the client not being significant. Forcing the client > to provide an identity breaks capability-based messaging. Just because it provides one doesn't mean it's significant. The client could've made up the identity on the spot. The important thing about client identity is that a consistent client identity can be used by the server to develop a trust relationship over time. The whole goal of my protocol is not necessarily to implement a capability-based security model, but to allow people a natural way to move their current sophisticated systems for assigning trust into the net by providing some kind of way for people to recognize eachother when they talk to one another. > Yes, each application protocol needs 'something' to enforce the > y-property in its introductions. You can add this 'something' by > defining a new protocol and building a proxy server for each > existing application protocol, or by extending the existing > application protocol. I submit that extending the existing > application protocol makes better use of existing resources, and > is the path of least resistance. I think the ideas are young enough that this isn't the case. In fact, I think key based routing is the next big step in the evolution of the net. > Realize that the implementation work is only a small part of the > task of deploying a new protocol. The evangelising work is the > toughest part. I think you underestimate the task ahead of you > with CAKE. There are those in the cryptography community that > believe that any new TCP/IP based protocol that does not use TLS > is snake-oil. By creating a new encryption protocol, you are > competing head-on with TLS and its supporters. There are ways to get a protocol into widespread acceptance without the blessing of the cryptography community. They won't work if repeatedly abused, so I won't reveal the precise details of what I intend. I will say I won't take the step until I feel I've done all I can to verify the my protocol sucessfully meets its design goals, and those goals are well documented. > > That isn't sufficient. Public keys wear out for more reasons than use. > > Have you carefully studied the reasons, and the attacks to be > thwarted? Do you have a link? It's mainly the public keys have a severely limited lifetime due to advances in computing hardware and technniques for factoring or finding discrete logs. I want a public key to be able to protect my data for 30 years. It's likely, today, that a 2048 bit RSA key meets that criteria. It will be much less likely 5 years from now. Keys need to be reissued regularily to try to keep ahead of the game. But, you address that issue with the old resource introducing the new idea, so its moot. That neatly sidesteps the whole 'CA' requirement for using a public key to sign things. > The HTTPSY protocol can be used as a replacement for DNS. See the > definition of the httpsy URL scheme: > > http://www.waterken.com/dev/YURL/httpsy/#The_httpsy_scheme > > I don't see how any of us can escape IP. A redirection service escapes IP by allowing the IP associated with a public key to be highly variable. > I also need to do this for the httpsy protocol. I'd appreciate it > if you could post information on how to do this. http://protozilla.mozdev.org > You'll still have to open a TCP session to get the response back. > The response won't fit in a UDP packet. This is true. I was thinking of delivering HTTP requests in email and getting the responses back in the same way. :-) That's rather silly for the eventual use of the protocol with http though, so you are correct. > Interesting, can you explain or provide links? Since the protocol doesn't provide replay protection for non-session oriented messages, an attacker could simply send the same message over and over. It wouldn't even have to be a message originating from one of the attacker's pk-ids, but any message at all. It would be very hard for the server to detect this was happening and to respond appropriately. > I have also been working on a UDP protocol that implements the > y-property, but for different reasons. I'll announce it here when > the spec is ready. Perhaps there will be a collaboration > opportunity. There might be. :-) Thinking of my system in terms of capability based security is an interesting exercise. I don't have a lot of practice doing that, and it's useful because it will probably tell me worthwhile things. I have a lot of respect for the capability based model. Have fun (if at all possible), -- There's an excellent C/C++/Python/Unix/Linux programmer with a wide range of other experience and system admin skills who needs work. Namely, me. http://www.omnifarious.org/~hopper/resume.html -- Eric Hopper -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 185 bytes Desc: This is a digitally signed message part Url : http://zgp.org/pipermail/p2p-hackers/attachments/20030822/14186d9e/attachment.pgp From zooko at zooko.com Fri Aug 22 09:39:02 2003 From: zooko at zooko.com (Zooko) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] decentralized incentive engineering: GNUnet Message-ID: Hello mnet-devel and p2p-hackers. I've written some notes about a GNUnet paper and put it on my "http://zooko.com/reading.html". After waiting in vain, for about an hour, for my friends to check my web page and write letters to me about decentralized incentive engineering, I lost patience and decided to send it to these lists. --Zooko An Excess-Based Economic Model for Resource Allocation in Peer-to-Peer Networks dura-link [1] v1.0.1 entry above [2] This is a reasonable stab at the problem from an engineering approach. The ideas are actually implemented, as I understand it, in GNUnet. It is completely decentralized, and they've given thought to the detailed problems: newbies, transitive operations, systemic attack resistance. It feels like exploratory work, and the author admits as much. He includes, for example, a "proof" that the attack resistance of the system as a whole is bounded by the attacker's bandwidth, but it is so specific to GNUnet's design and its assumptions that it isn't an exciting general result. These GNUnet-specific assumptions include that all traffic is request-response pairs, the requests are the only things that trigger consumption of resources, the responses are verifiable (except that this verification isn't yet implemented in the current GNUnet), and so on. Still, to his credit the author is clear that this is exploratory, and he clearly indicates his plans for future work. On a personal note, it is bittersweet to see some ideas that we implemented in Mojo Nation being reinvented here, such as the central notion of "excess-based" accounting, in which services are free when the server is idle anyway. I don't feel pride about this -- rather I feel regret that we didn't document what we did, and gratitude that the GNUnet folks are doing the world a better service by documenting their ideas. Also, of course, GNUnet is not identical to Mojo Nation, as GNUnet lacks the centralized component that Mojo Nation had. The basic approach that GNUnet takes to decentralized incentives is very like what I've been planning for Mnet v0.7. For anyone out there who is familiar with Mojo Nation, it is pretty much what you get by leaving the "KEEP_RUNNING_WHEN_TOKENSERVER_IS_DOWN" flag set and then adding some tweaks to favor the most useful of your peers. If you are interested in decentralized incentives in Mnet v0.7, you should read this paper. [1] http://zooko.com/reading.html#notes_GNUnet_ExcessBased_Economics [2] http://zooko.com/reading.html#entry_GNUnet_ExcessBased_Economics From tyler at waterken.com Fri Aug 22 13:59:01 2003 From: tyler at waterken.com (Tyler Close) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] CAKE = Key Addressed Crypto Encapsulationj In-Reply-To: <1061565982.30074.272.camel@monster.omnifarious.org> References: <1061352085.30074.24.camel@monster.omnifarious.org> <1061565982.30074.272.camel@monster.omnifarious.org> Message-ID: On Friday 22 August 2003 11:26, Eric M. Hopper wrote: > >?I also need to do this for the httpsy protocol. I'd appreciate it > >?if you could post information on how to do this. > > http://protozilla.mozdev.org It looks like the mailing list referenced on this page does not exist anymore. Anyone know where it went? Protozilla helps you setup a hook for a new URI scheme, but it leaves you on your own to implement the protocol. Ideally, I'd like to reuse the HTTP protocol handler already in Mozilla. Any idea how to get at it from the Protozilla plugin? Tyler -- The union of REST and capability-based security: http://www.waterken.com/dev/Web/ From zooko at zooko.com Fri Aug 22 14:12:02 2003 From: zooko at zooko.com (Zooko) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] unhappy realization: Kademlia doesn't self-heal (and Chord is rigid) Message-ID: Greetings, mnet-devel and p2p-hackers: I've long planned to use Kademlia [1] / Pastry [2] as the basis for the next routing system in Mnet. I've even written some code [3], and some documentation [4]. Nothing helps me understand an idea like implementing it, and in implementing my network (which I name "ent"), I stumbled upon the question: what if the Kademlia property doesn't hold? The Kademlia property is: "each node has a link to at least one node in each other subtree, if there are any nodes in that subtree". It is easy to find graphs where this property doesn't hold, but there is no obvious way for the nodes to detect or correct the error. If this were to happen, then a "crack" would appear, in which routing would sometimes fail -- by which I mean that a node would be part of the network, but a message sent to that node would not reach it. Worse, there is no obvious argument that this "crack" in the network would *ever* be repaired in normal use. It is plausible that the longer such a network runs, the more such "cracks" would accumulate. The authors of Kademlia (and of the closely related and earlier Pastry) address this concern with the application of redundancy. Their strategy seems to be that there will be K redundant links in each place where one link is required, and K will be chosen to be big enough so that there is a very small chance of all K of the links failing within the same time window of size T, and the nodes will proactively test and repair their set of K links every T time. For several reasons I find this solution to be unappealing. Thinking about these things reminded me of that excellent paper by David Liben-Nowell, Hari Balakrishnan, David Karger: "Observations on the Dynamic Evolution of Peer-to-Peer Networks" [5]. Re-reading that paper now, I see that Liben-Nowell at alia forsaw precisely my concern, and designed a mechanism for Chord that does exactly what I want. They wrote: "We also outline and analyze an algorithm that converges to a correct routing state from an arbitrary initial condition.". Okay, so that is exactly what I wanted. Except that I don't want Chord -- I want the "free choice" feature offered by Kademlia and Pastry, which is named "proximity neighbor selection" in this excellent paper [7]. So here are possible solutions to this conundrum: 1. Design a self-healing-from-arbitrary-initial-state protocol for Kademlia/Pastry. 2. Design a free-choice variant of Chord (as already mentioned on this list [6]). 3. ? I eagerly await your replies. Regards, Zooko http://zooko.com/log.html [1] http://citeseer.nj.nec.com/529075.html [2] http://research.microsoft.com/~antr/Pastry/pubs.htm [3] http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mnet/mnet_new/mnetlib/ent.py?rev=1.1.2.36&only_with_tag=newnet&content-type=text/vnd.viewcvs-markup [4] http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/mnet/mnet_new/doc/ent.html [5] http://citeseer.nj.nec.com/liben-nowell02observations.html [6] http://research.microsoft.com/~antr/Pastry/pubs.htm [7] http://citeseer.nj.nec.com/castro02exploiting.html [8] http://zgp.org/pipermail/p2p-hackers/2003-March/thread.html#1157 From zooko at zooko.com Fri Aug 22 14:18:02 2003 From: zooko at zooko.com (Zooko) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] unhappy realization: Kademlia doesn't self-heal (and Chord is rigid) In-Reply-To: Message from "Zooko" of "22 Aug 2003 17:10:03 EDT." References: Message-ID: [following up to my own post to correct a typo in enumerating footnotes] > 1. Design a self-healing-from-arbitrary-initial-state protocol for > Kademlia/Pastry. > > 2. Design a free-choice variant of Chord (as already mentioned on this > list [6]). ^-- this should say [8]. footnote [6] wasn't actually referenced, but you should read it anyway if you haven't. > I eagerly await your replies. > > Regards, > > Zooko > > http://zooko.com/log.html > > [1] http://citeseer.nj.nec.com/529075.html > [2] http://research.microsoft.com/~antr/Pastry/pubs.htm > [3] http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mnet/mnet_new/mnetlib/ent.py?rev=1.1.2.36&only_with_tag=newnet&content-type=text/vnd.viewcvs-markup > [4] http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/mnet/mnet_new/doc/ent.html > [5] http://citeseer.nj.nec.com/liben-nowell02observations.html > [6] http://research.microsoft.com/~antr/Pastry/pubs.htm > [7] http://citeseer.nj.nec.com/castro02exploiting.html > [8] http://zgp.org/pipermail/p2p-hackers/2003-March/thread.html#1157 From bert at web2peer.com Fri Aug 22 15:11:01 2003 From: bert at web2peer.com (Bert) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] unhappy realization: Kademlia doesn't self-heal (and Chord is rigid) Message-ID: <20030822151046.27542.h016.c001.wm@mail.web2peer.com.criticalpath.net> Check out Symphony, which I cite below. It's a probabilistic approach, but given that the net is so unpredictable, (effectively) so are all other approaches :-) =================================== Gurmeet S Manku, Mayank Bawa and Prabhakar Raghavan Symphony: Distributed Hashing in a Small World, In USITS, 2003. We present Symphony, a novel protocol for maintaining distributed hash tables in a wide area network. The key idea is to arrange all participants along a ring and equip them with long distance contacts drawn from a family of harmonic distributions. Through simulation, we demonstrate that our construction is scalable, flexible, stable in the presence of frequent updates and offers small average latency with only a handful of long distance links per node. The cost of updates when hosts join and leave is small. On 22 Aug 2003 17:15:45 -0400, "Zooko" wrote: > > > [following up to my own post to correct a typo in enumerating > footnotes] > > > 1. Design a self-healing-from-arbitrary-initial-state protocol for > > Kademlia/Pastry. > > > > 2. Design a free-choice variant of Chord (as already mentioned on > this > > list [6]). > ^-- this should say [8]. > > footnote [6] wasn't actually referenced, but you should read it anyway > if you haven't. > > > I eagerly await your replies. > > > > Regards, > > > > Zooko > > > > http://zooko.com/log.html > > > > [1] http://citeseer.nj.nec.com/529075.html > > [2] http://research.microsoft.com/~antr/Pastry/pubs.htm > > [3] > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mnet/mnet_new/mnetlib/ent.py?rev=1.1.2.36&only_with_tag=newnet&content-type=text/vnd.viewcvs-markup > > [4] > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/mnet/mnet_new/doc/ent.html > > [5] http://citeseer.nj.nec.com/liben-nowell02observations.html > > [6] http://research.microsoft.com/~antr/Pastry/pubs.htm > > [7] http://citeseer.nj.nec.com/castro02exploiting.html > > [8] http://zgp.org/pipermail/p2p-hackers/2003-March/thread.html#1157 > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences From bert at web2peer.com Fri Aug 22 15:11:03 2003 From: bert at web2peer.com (Bert) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] unhappy realization: Kademlia doesn't self-heal (and Chord is rigid) Message-ID: <20030822151046.27542.h016.c001.wm@mail.web2peer.com.criticalpath.net> Check out Symphony, which I cite below. It's a probabilistic approach, but given that the net is so unpredictable, (effectively) so are all other approaches :-) =================================== Gurmeet S Manku, Mayank Bawa and Prabhakar Raghavan Symphony: Distributed Hashing in a Small World, In USITS, 2003. We present Symphony, a novel protocol for maintaining distributed hash tables in a wide area network. The key idea is to arrange all participants along a ring and equip them with long distance contacts drawn from a family of harmonic distributions. Through simulation, we demonstrate that our construction is scalable, flexible, stable in the presence of frequent updates and offers small average latency with only a handful of long distance links per node. The cost of updates when hosts join and leave is small. On 22 Aug 2003 17:15:45 -0400, "Zooko" wrote: > > > [following up to my own post to correct a typo in enumerating > footnotes] > > > 1. Design a self-healing-from-arbitrary-initial-state protocol for > > Kademlia/Pastry. > > > > 2. Design a free-choice variant of Chord (as already mentioned on > this > > list [6]). > ^-- this should say [8]. > > footnote [6] wasn't actually referenced, but you should read it anyway > if you haven't. > > > I eagerly await your replies. > > > > Regards, > > > > Zooko > > > > http://zooko.com/log.html > > > > [1] http://citeseer.nj.nec.com/529075.html > > [2] http://research.microsoft.com/~antr/Pastry/pubs.htm > > [3] > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mnet/mnet_new/mnetlib/ent.py?rev=1.1.2.36&only_with_tag=newnet&content-type=text/vnd.viewcvs-markup > > [4] > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/mnet/mnet_new/doc/ent.html > > [5] http://citeseer.nj.nec.com/liben-nowell02observations.html > > [6] http://research.microsoft.com/~antr/Pastry/pubs.htm > > [7] http://citeseer.nj.nec.com/castro02exploiting.html > > [8] http://zgp.org/pipermail/p2p-hackers/2003-March/thread.html#1157 > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences From gojomo at bitzi.com Fri Aug 22 15:23:02 2003 From: gojomo at bitzi.com (Gordon Mohr) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] unhappy realization: Kademlia doesn't self-heal (and Chord is rigid) References: Message-ID: <011401c368fb$892fb130$3df0edd1@gojovaio> Zooko writes: > Nothing helps me understand an idea like implementing it, and in implementing > my network (which I name "ent"), I stumbled upon the question: what if the > Kademlia property doesn't hold? The Kademlia property is: "each node has a > link to at least one node in each other subtree, if there are any nodes in > that subtree". > > It is easy to find graphs where this property doesn't hold, but there is no > obvious way for the nodes to detect or correct the error. If this were to > happen, then a "crack" would appear, in which routing would sometimes fail -- > by which I mean that a node would be part of the network, but a message sent > to that node would not reach it. Worse, there is no obvious argument that > this "crack" in the network would *ever* be repaired in normal use. It is > plausible that the longer such a network runs, the more such "cracks" would > accumulate. Without referring back to the source: I thought that Kademlia took advantage of even lookup traffic towards you to update the bins. Thus, even if only one other peer in the network knows of your existence, it'll eventually refer some lookups your way. These lookups are equally likely to have originated anywhere in the address space, so they will bring you knowledge of new peers to fill up your bins with active, diverse peers. Similarly, while it's always *best* to send your lookups to a peer in the "right" direction, I don't think it's illegal to try sending them through non-optimal hosts. Their reaction -- either redirecting you elsewhere or relaying your lookup to better peers (who may eventually acknowledge your lookup) -- inevitably informs you of new peers, to better fill your lookup bins. Even if neither of these processes actually occur, one simple new message -- suggest me some new peers in these areas where I'm needy -- could make intentional mending from arbitrary (but not hopelessly disconnected) initial states fairly easy. - Gojomo From bert at web2peer.com Fri Aug 22 15:35:02 2003 From: bert at web2peer.com (Bert) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] unhappy realization: Kademlia doesn't self-heal (and Chord is rigid) Message-ID: <20030822153415.7854.h017.c001.wm@mail.web2peer.com.criticalpath.net> I should have clarified that Symphony doesn't directly address your desire for proximity based choice of neighbors, but since it selects long-distance links from harmanonic distributions of peers (instead of using the rigid Chord-like approach) it shouldn't be too difficult to work this in. On Fri, 22 Aug 2003 15:10:44 -0700 (PDT), "Bert" wrote: > > Check out Symphony, which I cite below. It's a probabilistic approach, > but given that the net is so unpredictable, (effectively) so are all > other approaches :-) > > > =================================== > Gurmeet S Manku, Mayank Bawa and Prabhakar Raghavan Symphony: > Distributed Hashing in a Small World, In USITS, 2003. > > We present Symphony, a novel protocol for maintaining distributed hash > tables in a wide area network. The key idea is to arrange all > participants along a ring and equip them with long distance contacts > drawn from a family of harmonic distributions. Through simulation, we > demonstrate that our construction is scalable, flexible, stable in the > presence of frequent updates and offers small average latency with > only a handful of long distance links per node. The cost of updates > when hosts join and leave is small. > > > > On 22 Aug 2003 17:15:45 -0400, "Zooko" wrote: > > > > > > > [following up to my own post to correct a typo in enumerating > > footnotes] > > > > > 1. Design a self-healing-from-arbitrary-initial-state protocol > for > > > Kademlia/Pastry. > > > > > > 2. Design a free-choice variant of Chord (as already mentioned on > > this > > > list [6]). > > ^-- this should say [8]. > > > > footnote [6] wasn't actually referenced, but you should read it > anyway > > if you haven't. > > > > > I eagerly await your replies. > > > > > > Regards, > > > > > > Zooko > > > > > > http://zooko.com/log.html > > > > > > [1] http://citeseer.nj.nec.com/529075.html > > > [2] http://research.microsoft.com/~antr/Pastry/pubs.htm > > > [3] > > > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mnet/mnet_new/mnetlib/ent.py?rev=1.1.2.36&only_with_tag=newnet&content-type=text/vnd.viewcvs-markup > > > [4] > > > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/mnet/mnet_new/doc/ent.html > > > [5] http://citeseer.nj.nec.com/liben-nowell02observations.html > > > [6] http://research.microsoft.com/~antr/Pastry/pubs.htm > > > [7] http://citeseer.nj.nec.com/castro02exploiting.html > > > [8] > http://zgp.org/pipermail/p2p-hackers/2003-March/thread.html#1157 > > _______________________________________________ > > p2p-hackers mailing list > > p2p-hackers@zgp.org > > http://zgp.org/mailman/listinfo/p2p-hackers > > _______________________________________________ > > Here is a web page listing P2P Conferences: > > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences From bert at web2peer.com Fri Aug 22 15:35:04 2003 From: bert at web2peer.com (Bert) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] unhappy realization: Kademlia doesn't self-heal (and Chord is rigid) Message-ID: <20030822153415.7854.h017.c001.wm@mail.web2peer.com.criticalpath.net> I should have clarified that Symphony doesn't directly address your desire for proximity based choice of neighbors, but since it selects long-distance links from harmanonic distributions of peers (instead of using the rigid Chord-like approach) it shouldn't be too difficult to work this in. On Fri, 22 Aug 2003 15:10:44 -0700 (PDT), "Bert" wrote: > > Check out Symphony, which I cite below. It's a probabilistic approach, > but given that the net is so unpredictable, (effectively) so are all > other approaches :-) > > > =================================== > Gurmeet S Manku, Mayank Bawa and Prabhakar Raghavan Symphony: > Distributed Hashing in a Small World, In USITS, 2003. > > We present Symphony, a novel protocol for maintaining distributed hash > tables in a wide area network. The key idea is to arrange all > participants along a ring and equip them with long distance contacts > drawn from a family of harmonic distributions. Through simulation, we > demonstrate that our construction is scalable, flexible, stable in the > presence of frequent updates and offers small average latency with > only a handful of long distance links per node. The cost of updates > when hosts join and leave is small. > > > > On 22 Aug 2003 17:15:45 -0400, "Zooko" wrote: > > > > > > > [following up to my own post to correct a typo in enumerating > > footnotes] > > > > > 1. Design a self-healing-from-arbitrary-initial-state protocol > for > > > Kademlia/Pastry. > > > > > > 2. Design a free-choice variant of Chord (as already mentioned on > > this > > > list [6]). > > ^-- this should say [8]. > > > > footnote [6] wasn't actually referenced, but you should read it > anyway > > if you haven't. > > > > > I eagerly await your replies. > > > > > > Regards, > > > > > > Zooko > > > > > > http://zooko.com/log.html > > > > > > [1] http://citeseer.nj.nec.com/529075.html > > > [2] http://research.microsoft.com/~antr/Pastry/pubs.htm > > > [3] > > > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mnet/mnet_new/mnetlib/ent.py?rev=1.1.2.36&only_with_tag=newnet&content-type=text/vnd.viewcvs-markup > > > [4] > > > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/mnet/mnet_new/doc/ent.html > > > [5] http://citeseer.nj.nec.com/liben-nowell02observations.html > > > [6] http://research.microsoft.com/~antr/Pastry/pubs.htm > > > [7] http://citeseer.nj.nec.com/castro02exploiting.html > > > [8] > http://zgp.org/pipermail/p2p-hackers/2003-March/thread.html#1157 > > _______________________________________________ > > p2p-hackers mailing list > > p2p-hackers@zgp.org > > http://zgp.org/mailman/listinfo/p2p-hackers > > _______________________________________________ > > Here is a web page listing P2P Conferences: > > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences From bert at web2peer.com Fri Aug 22 15:35:06 2003 From: bert at web2peer.com (Bert) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] unhappy realization: Kademlia doesn't self-heal (and Chord is rigid) Message-ID: <20030822153415.7854.h017.c001.wm@mail.web2peer.com.criticalpath.net> I should have clarified that Symphony doesn't directly address your desire for proximity based choice of neighbors, but since it selects long-distance links from harmanonic distributions of peers (instead of using the rigid Chord-like approach) it shouldn't be too difficult to work this in. On Fri, 22 Aug 2003 15:10:44 -0700 (PDT), "Bert" wrote: > > Check out Symphony, which I cite below. It's a probabilistic approach, > but given that the net is so unpredictable, (effectively) so are all > other approaches :-) > > > =================================== > Gurmeet S Manku, Mayank Bawa and Prabhakar Raghavan Symphony: > Distributed Hashing in a Small World, In USITS, 2003. > > We present Symphony, a novel protocol for maintaining distributed hash > tables in a wide area network. The key idea is to arrange all > participants along a ring and equip them with long distance contacts > drawn from a family of harmonic distributions. Through simulation, we > demonstrate that our construction is scalable, flexible, stable in the > presence of frequent updates and offers small average latency with > only a handful of long distance links per node. The cost of updates > when hosts join and leave is small. > > > > On 22 Aug 2003 17:15:45 -0400, "Zooko" wrote: > > > > > > > [following up to my own post to correct a typo in enumerating > > footnotes] > > > > > 1. Design a self-healing-from-arbitrary-initial-state protocol > for > > > Kademlia/Pastry. > > > > > > 2. Design a free-choice variant of Chord (as already mentioned on > > this > > > list [6]). > > ^-- this should say [8]. > > > > footnote [6] wasn't actually referenced, but you should read it > anyway > > if you haven't. > > > > > I eagerly await your replies. > > > > > > Regards, > > > > > > Zooko > > > > > > http://zooko.com/log.html > > > > > > [1] http://citeseer.nj.nec.com/529075.html > > > [2] http://research.microsoft.com/~antr/Pastry/pubs.htm > > > [3] > > > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mnet/mnet_new/mnetlib/ent.py?rev=1.1.2.36&only_with_tag=newnet&content-type=text/vnd.viewcvs-markup > > > [4] > > > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/mnet/mnet_new/doc/ent.html > > > [5] http://citeseer.nj.nec.com/liben-nowell02observations.html > > > [6] http://research.microsoft.com/~antr/Pastry/pubs.htm > > > [7] http://citeseer.nj.nec.com/castro02exploiting.html > > > [8] > http://zgp.org/pipermail/p2p-hackers/2003-March/thread.html#1157 > > _______________________________________________ > > p2p-hackers mailing list > > p2p-hackers@zgp.org > > http://zgp.org/mailman/listinfo/p2p-hackers > > _______________________________________________ > > Here is a web page listing P2P Conferences: > > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences From gbildson at limepeer.com Fri Aug 22 15:44:02 2003 From: gbildson at limepeer.com (Greg Bildson) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] unhappy realization: Kademlia doesn't self-heal (and Chord is rigid) In-Reply-To: <20030822153415.7854.h017.c001.wm@mail.web2peer.com.criticalpath.net> Message-ID: Please stop cc'ing the list twice along with sending to the list. Thanks -greg From hopper at omnifarious.org Fri Aug 22 17:52:02 2003 From: hopper at omnifarious.org (Eric M. Hopper) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] unhappy realization: Kademlia doesn't self-heal (and Chord is rigid) In-Reply-To: References: Message-ID: <1061599908.30074.288.camel@monster.omnifarious.org> On Fri, 2003-08-22 at 16:10, Zooko wrote: > Greetings, mnet-devel and p2p-hackers: > > I've long planned to use Kademlia [1] / Pastry [2] as the basis for the next > routing system in Mnet. I've even written some code [3], and some > documentation [4]. Wouldn't a routing system based on Kademlia end up being topographically inefficient? I would prefer my packets follow the physical link topography as closely as possible. Does this happen in Kademlia and I just don't realize it? I can see a system based on Kademlia for storing information about how to reach nodes using a protocol that's efficiently routed. But it doesn't seem like the Kademlia is itself good for routing bulk data. Is there a specific article you can point me to showing that my impressions are wrong? Thanks, -- There's an excellent C/C++/Python/Unix/Linux programmer with a wide range of other experience and system admin skills who needs work. Namely, me. http://www.omnifarious.org/~hopper/resume.html -- Eric Hopper -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 185 bytes Desc: This is a digitally signed message part Url : http://zgp.org/pipermail/p2p-hackers/attachments/20030822/33ee134e/attachment.pgp From hopper at omnifarious.org Fri Aug 22 21:16:01 2003 From: hopper at omnifarious.org (Eric M. Hopper) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] unhappy realization: Kademlia doesn't self-heal (and Chord is rigid) In-Reply-To: <1061599908.30074.288.camel@monster.omnifarious.org> References: <1061599908.30074.288.camel@monster.omnifarious.org> Message-ID: <1061612146.30074.291.camel@monster.omnifarious.org> On Fri, 2003-08-22 at 19:51, Eric M. Hopper wrote: > On Fri, 2003-08-22 at 16:10, Zooko wrote: > > Greetings, mnet-devel and p2p-hackers: > > > > I've long planned to use Kademlia [1] / Pastry [2] as the basis for the next > > routing system in Mnet. I've even written some code [3], and some > > documentation [4]. > > Wouldn't a routing system based on Kademlia end up being topographically > inefficient? I would prefer my packets follow the physical link > topography as closely as possible. Does this happen in Kademlia and I > just don't realize it? Now, that was a silly question. :-) Obviously, I only had the vaguest clue how it worked. :-) *sigh*, -- There's an excellent C/C++/Python/Unix/Linux programmer with a wide range of other experience and system admin skills who needs work. Namely, me. http://www.omnifarious.org/~hopper/resume.html -- Eric Hopper -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 185 bytes Desc: This is a digitally signed message part Url : http://zgp.org/pipermail/p2p-hackers/attachments/20030822/497b5045/attachment.pgp From zooko at zooko.com Sat Aug 23 13:39:02 2003 From: zooko at zooko.com (Zooko) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] Re: unhappy realization: Kademlia doesn't self-heal (and Chord is rigid) In-Reply-To: Message from "Gordon Mohr" of "Fri, 22 Aug 2003 15:20:03 PDT." <011401c368fb$892fb130$3df0edd1@gojovaio> References: <011401c368fb$892fb130$3df0edd1@gojovaio> Message-ID: "Gordon Mohr" wrote: > > I thought that Kademlia took advantage of even lookup traffic towards > you to update the bins. Thus, even if only one other peer in the network > knows of your existence, it'll eventually refer some lookups your > way. These lookups are equally likely to have originated anywhere > in the address space, so they will bring you knowledge of new peers > to fill up your bins with active, diverse peers. This would work to heal some sorts of flaws, but not the kind I am thinking of. There could be a "crack" in the Kademlia tree such that you will not see any traffic from nodes which are separated from you by the crack. The unidirectional and symmetric nature of the XOR metric seems to dictate that if you can't route to them, they can't route to you. > Similarly, while it's always *best* to send your lookups to a peer in > the "right" direction, I don't think it's illegal to try sending them > through non-optimal hosts. Their reaction -- either redirecting you > elsewhere or relaying your lookup to better peers (who may eventually > acknowledge your lookup) -- inevitably informs you of new peers, to > better fill your lookup bins. > > Even if neither of these processes actually occur, one simple new > message -- suggest me some new peers in these areas where I'm needy -- > could make intentional mending from arbitrary (but not hopelessly > disconnected) initial states fairly easy. This pair of related techniques *would* have a chance of healing a crack. They are very like something I have been working on, inspired in part by the "random waypoint" technique used in [1] for load-balancing. Regards, Zooko [1] http://citeseer.nj.nec.com/wieder02novel.html From baford at mit.edu Sun Aug 24 09:20:02 2003 From: baford at mit.edu (Bryan Ford) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] unhappy realization: Kademlia doesn't self-heal (and Chord is rigid) Message-ID: <200308241219.00700.baford@mit.edu> Zooko writes: > Nothing helps me understand an idea like implementing it, and in implementing > my network (which I name "ent"), I stumbled upon the question: what if the > Kademlia property doesn't hold? The Kademlia property is: "each node has a > link to at least one node in each other subtree, if there are any nodes in > that subtree". > > It is easy to find graphs where this property doesn't hold, but there is no > obvious way for the nodes to detect or correct the error. If this were to > happen, then a "crack" would appear, in which routing would sometimes fail -- > by which I mean that a node would be part of the network, but a message sent > to that node would not reach it. Worse, there is no obvious argument that > this "crack" in the network would *ever* be repaired in normal use. It is > plausible that the longer such a network runs, the more such "cracks" would > accumulate. Then Gojomo responds: [...] >Similarly, while it's always *best* to send your lookups to a peer in >the "right" direction, I don't think it's illegal to try sending them >through non-optimal hosts. Their reaction -- either redirecting you >elsewhere or relaying your lookup to better peers (who may eventually >acknowledge your lookup) -- inevitably informs you of new peers, to >better fill your lookup bins. > >Even if neither of these processes actually occur, one simple new >message -- suggest me some new peers in these areas where I'm needy -- >could make intentional mending from arbitrary (but not hopelessly >disconnected) initial states fairly easy. Unfortunately if you analyze the Kademlia protocol a little more carefully I think you'll find that there are initial states from which (at least with the basic, unmodified Kademlia protocol) full network connectivity is not likely to be restored for a very long time, if ever. Consider two large Kademlia networks that initially evolve independently and are fully disconnected from each other, but each of these networks itself is correct and fully-connected. Say each network has size N = 2^n nodes, meaning that the first 'n' buckets in each node's neighbor table will usually be populated while the rest will usually be empty (with occasional slight deviations depending on how evenly nodes are distributed in identifier space). Furthermore assume that each bucket has 'k' entries, and that N >> k (which is typically true in practice - e.g., 'k' might typically be 5 or 10, whereas we hope N could be in the thousands or eventually perhaps even millions or billions). Now suppose we pick some node A in the first network whose identifier begins with a 0 bit, and some node B in the second network whose identifier begins with a 1 bit, and introduce a link between them, effectively joining the two networks with a single "bucket 0" link. Although the two original networks were correct and fully-connected, the one resulting "big" network is incorrect and in fact rather poorly connected: a node in either original network has almost no chance of reaching a node on the other "side", because the subnetworks represented by higher-numbered buckets form entirely separate "cliques" established during the evolution of the two original networks. Furthermore, there is no reason the basic Kademlia protocol is likely to rectify this situation very quickly, if ever, during its normal operation: _all_ the nodes in both networks no doubt already have full 0-buckets (and 1-buckets and ... (n-log2 k) buckets, so why should they believe this new 0-bucket link between A and B is in any way special and worthy of propagation to other nodes? This is a worst-case but not necessarily terribly unlikely example; occasional net splits are a fact of life. Smaller net splits can create similar problems at any level of the Kademlia routing hierarchy. I believe that the severity of this problem in Kademlia is in part a direct consequence of the freedom the Kademlia protocol gives nodes in choosing their neighbors. I still believe that this freedom is a very good thing, but we must find a different way to solve the healing problem, since the "loopy network" detection and resolution technique developed by Liben-Nowell et al for Chord simply doesn't work in a network like Kademlia where the mandated neighbor relationships don't necessarily form some kind of global ring. I have a possible solution in mind, involving network reachability fingerprints that are vaguely analogous to document similarity fingerprints, that would allow nodes to recognize immediately when some newly created or discovered link is simply another redundant link in an already largely well-connected Kademlia network or leads to a substantially different network that needs to be explored and merged in. I'm just starting some simulations on this idea; I'd be happy to talk about it more off-list if you like. I'm working on this in the context of my aforementioned UIP project (http://uip.sourceforge.net/), and the draft paper available on that site contains a very brief section (section 3.5) on merging and healing. This fingerprint-based healing method may be applicable to other types of DHTs as well, and is certainly applicable to other _uses_ of Kademlia-like DHTs besides the use I'm trying to put it to (network-layer routing). But my healing technique is still immature and untested, and there may well be other much better ways in any case; only time will tell. Cheers, Bryan From zooko at zooko.com Sun Aug 24 09:24:02 2003 From: zooko at zooko.com (Zooko) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] unhappy realization: Kademlia doesn't self-heal (and Chord is rigid) In-Reply-To: Message from Bryan Ford of "Sun, 24 Aug 2003 12:19:00 EDT." <200308241219.00700.baford@mit.edu> References: <200308241219.00700.baford@mit.edu> Message-ID: Bryan Ford wrote: > > Unfortunately if you analyze the Kademlia protocol a little more carefully I > think you'll find that there are initial states from which (at least with the > basic, unmodified Kademlia protocol) full network connectivity is not likely > to be restored for a very long time, if ever. I came to this same conclusion last night. > Consider two large Kademlia networks that initially evolve independently and > are fully disconnected from each other, but each of these networks itself is ... > Now suppose we pick some node A in the first network whose identifier begins > with a 0 bit, and some node B in the second network whose identifier begins > with a 1 bit, and introduce a link between them, effectively joining the two I came to this same example last night! > I have a possible solution in mind, involving network reachability > fingerprints that are vaguely analogous to document similarity fingerprints, Holy cow! I came to this same idea last night! Heh heh... Well, I will read up on the the docs you have published. Thank you for sharing your insights. In the meantime, my work on ent is now proceeding without any in-network solution to the "Self-Healing Kademlia" problem. At least for the time being, I expect extrinsic mechanisms to maintain the health of the network. Regards, Zooko From baford at mit.edu Sun Aug 24 10:04:01 2003 From: baford at mit.edu (Bryan Ford) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] unhappy realization: Kademlia doesn't self-heal In-Reply-To: <20030823102905.32347.48988.Mailman@capsicum.zgp.org> References: <20030823102905.32347.48988.Mailman@capsicum.zgp.org> Message-ID: <200308241303.02264.baford@mit.edu> Eric wrote: > > Wouldn't a routing system based on Kademlia end up being topographically > > inefficient? I would prefer my packets follow the physical link > > topography as closely as possible. Does this happen in Kademlia and I > > just don't realize it? ...then responded to himself: > Now, that was a silly question. :-) Obviously, I only had the vaguest > clue how it worked. :-) Actually, no, I don't think it's a silly question. The original Kademlia protocol (and most other DHTs) assumes that the underlying network is already fully-connected, so that once the appropriate destination node has been found using the DHT, subsequent bulk communication occurs directly using the underlying network-layer protocol (e.g., IP). In the case of my UIP project, however, I'm trying to use a Kademlia-like DHT to _create_ a network-layer routing protocol, which means possibly having to use these Kademlia routes for bulk communication as well as just lookup. Yes, the resulting routes can be very non-optimal at times, and yes, that's bad. :) On the hopeful side, however: - UIP only does its own routing whenever the underlying protocol (e.g., IP) fails to provide complete connectivity. For example, suppose UIP node A looks up UIP node B and finds it after an 8-hop lookup sequence. Then A gets back B's IP address and tries to establish a direct IP-based connection. If that works, great - we've just short-circuited all 8 hops. If it doesn't work, e.g., because A and B happen to be on different IP-based networks, only then do we have to use UIP-based routing. - Even when UIP-based routing is required, it's often possible to optimize the generated routes substantially: the original lookup path may criscross throughout the Kademlia network and even visit some nodes multiple times, but once we finish the lookup we can short-circuit many of those extra hops. I'm currently exploring two such optimization techniques via simulations, and should have results to report shortly. (I have some preliminary results already, which are not as good as I'd like but not hopeless either: so far an average hop count "stretch" of 2x seems typical, with a few really bad routes, e.g., 20x or 30x stretch, here and there.) In exchange for this non-optimality of the routes we come up with by using a Kademlia-like protocol to find them, we do get one important benefit: much lower mandatory storage requirements at each node. In general, network-layer routing protocols can only guarantee finding optimal routes if each node is willing to store up to O(N) routing state - i.e., some state about each possible other node. BGP reduces this state burden through a manually-administered address aggregation hierarchy, at the cost of no longer necessarily being able to find the optimal route to nodes on multi-homed subnetworks. But even with BGP's address aggregation hierarchy, core Internet routers have to manage huge routing tables. Using a Kademlia-like DHT to find routes is basically analogous, except now we're using an automatically-administered address aggregation hierarchy. Furthermore, the Kademlia-based protocol guarantees that we can maintain full network connectivity even if each node stores only O(log N) state, something BGP-based routing does not guarantee at all. The question is, how close to optimal do our routes need to be before we call it "useable", and how close to optimal is "good enough"? What is the best tradeoff between routing optimality/performance and state? And how much flexibility can we give individual nodes in deciding this tradeoff? With the Kademlia protocol, once a node has fulfilled its O(log N) state obligation, it is free to go beyond that and fill its buckets with many more neighbors than the minimum necessary, in order to have a better chance at finding optimal routes - but its neighbors are under no obligation to follow suit. With traditional distance-vector and BGP-like protocols it is appears more difficult to achieve this kind of flexibility. Cheers, Bryan From wesley at felter.org Sun Aug 24 21:20:02 2003 From: wesley at felter.org (Wes Felter) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] unhappy realization: Kademlia doesn't self-heal In-Reply-To: <200308241303.02264.baford@mit.edu> Message-ID: <0604DA2F-D6B4-11D7-BC0D-000393A581BE@felter.org> On Sunday, August 24, 2003, at 12:03 PM, Bryan Ford wrote: > - UIP only does its own routing whenever the underlying protocol > (e.g., IP) > fails to provide complete connectivity. For example, suppose UIP node > A > looks up UIP node B and finds it after an 8-hop lookup sequence. Then > A gets > back B's IP address and tries to establish a direct IP-based > connection. If > that works, great - we've just short-circuited all 8 hops. If it > doesn't > work, e.g., because A and B happen to be on different IP-based > networks, only > then do we have to use UIP-based routing. I've seen this in Tapestry/OceanStore as well, and it seems distasteful. Network-layer problems (e.g. lack of global connectivity) should be solved at the network layer (e.g. RON), not at the application layer. My gripe is less applicable to UIP because it's not an application. (Of course, a corollary of this principle is that apps shouldn't worry about NATs and let Teredo take care of it. I reluctantly admit that that's not realistic today.) Wes Felter - wesley@felter.org - http://felter.org/wesley/ From pfh at mail.csse.monash.edu.au Mon Aug 25 16:46:02 2003 From: pfh at mail.csse.monash.edu.au (Paul Harrison) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] unhappy realization: Kademlia doesn't self-heal (and Chord is rigid) In-Reply-To: <20030822153415.7854.h017.c001.wm@mail.web2peer.com.criticalpath.net> Message-ID: On Fri, 22 Aug 2003, Bert wrote: > I should have clarified that Symphony doesn't directly address your > desire for proximity based choice of neighbors, but since it selects > long-distance links from harmanonic distributions of peers (instead of > using the rigid Chord-like approach) it shouldn't be too difficult to > work this in. > If you have a preference for keeping links to physically close by nodes as well as close-by-name nodes, you'll end up with a mixture of links to physically and name-aly close nodes (obviously). A packet routing through the network will tend to hop around in your immediate physical vicinity a bit, then spiral out to its destination. To be a little more clever, you might even choose physically closer but name-aly slightly further links occasionally when routing messages, in case you have somehow ended up with some both physically and name-aly distant links. With larger numbers of links per node (which are virtual in any case, and therefore fairly cheap), i think routing using this could be close to optimal. Nifty :-) cheers, Paul Email: pfh@logarithmic.net IM: pfh on thecircle.org.au Current cost to save one life: approx AU$300 (US$200) From dmarti at zgp.org Wed Aug 27 16:57:37 2003 From: dmarti at zgp.org (Don Marti) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] Point of order: non-subscriber mail Message-ID: <20030827165737.GA1405@zgp.org> After dealing with a flood of spam this morning, Zooko and I have changed the list policy to silently discard mail from non-subscribers. I also upgraded to Mailman 2.1.2, so if you have a problem with the list please let me know. If you post to the list and your mail does not go through, you will need to check the subscription form at: http://zgp.org/mailman/listinfo/p2p-hackers to make sure you are subscribed from the correct address. -- Don Marti Reform copyright law -- return abandoned works http://zgp.org/~dmarti to the public domain after 50 years: dmarti@zgp.org http://www.PetitionOnline.com/eldred/petition.html KG6INA From justin at chapweske.com Wed Aug 27 18:41:51 2003 From: justin at chapweske.com (Justin Chapweske) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] Point of order: non-subscriber mail In-Reply-To: <20030827165737.GA1405@zgp.org> References: <20030827165737.GA1405@zgp.org> Message-ID: <3F4CFB6F.3050508@chapweske.com> Do you at least send some sort of bounce message to the sender? Admittedly, I often accidently send mail from the wrong account and wouldn't catch my error w/o a bounce. Thanks, -Justin Don Marti wrote: > After dealing with a flood of spam this morning, Zooko and > I have changed the list policy to silently discard mail from > non-subscribers. I also upgraded to Mailman 2.1.2, so if you have > a problem with the list please let me know. > > If you post to the list and your mail does not go through, you will > need to check the subscription form at: > > http://zgp.org/mailman/listinfo/p2p-hackers > > to make sure you are subscribed from the correct address. > -- Justin Chapweske, Onion Networks http://onionnetworks.com/ From hopper at omnifarious.org Wed Aug 27 18:48:40 2003 From: hopper at omnifarious.org (Eric M. Hopper) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] Point of order: non-subscriber mail In-Reply-To: <20030827165737.GA1405@zgp.org> References: <20030827165737.GA1405@zgp.org> Message-ID: <1062010120.18389.145.camel@monster.omnifarious.org> On Wed, 2003-08-27 at 11:57, Don Marti wrote: > After dealing with a flood of spam this morning, Zooko and > I have changed the list policy to silently discard mail from > non-subscribers. I also upgraded to Mailman 2.1.2, so if you have > a problem with the list please let me know. > > If you post to the list and your mail does not go through, you will > need to check the subscription form at: > > http://zgp.org/mailman/listinfo/p2p-hackers > > to make sure you are subscribed from the correct address. It would be nice to modify Mailman to check for a digital signature, and check the signature against keys submitted by subscribers, and let through any message signed by a subscriber no matter which address it came from. :-) Have fun (if at all possible), -- There's an excellent C/C++/Python/Unix/Linux programmer with a wide range of other experience and system admin skills who needs work. Namely, me. http://www.omnifarious.org/~hopper/resume.html -- Eric Hopper -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 185 bytes Desc: This is a digitally signed message part Url : http://zgp.org/pipermail/p2p-hackers/attachments/20030827/3b5b42eb/attachment.pgp From dmarti at zgp.org Wed Aug 27 18:51:16 2003 From: dmarti at zgp.org (Don Marti) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] Point of order: non-subscriber mail In-Reply-To: <3F4CFB6F.3050508@chapweske.com> References: <20030827165737.GA1405@zgp.org> <3F4CFB6F.3050508@chapweske.com> Message-ID: <20030827185116.GQ1405@zgp.org> begin Justin Chapweske quotation of Wed, Aug 27, 2003 at 01:41:51PM -0500: > Do you at least send some sort of bounce message to the sender? Unfortunately, the spam we cleaned out this morning was from forged addresses. If we chose to "reject" instead of "discard" we would be spamming innocent people or postmasters. -- Don Marti Reform copyright law -- return abandoned works http://zgp.org/~dmarti to the public domain after 50 years: dmarti@zgp.org http://www.PetitionOnline.com/eldred/petition.html KG6INA From blair at orcaware.com Wed Aug 27 19:53:13 2003 From: blair at orcaware.com (Blair Zajac) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] Point of order: non-subscriber mail References: <20030827165737.GA1405@zgp.org> Message-ID: <3F4D0C29.17A60DAA@orcaware.com> Don Marti wrote: > > After dealing with a flood of spam this morning, Zooko and > I have changed the list policy to silently discard mail from > non-subscribers. I also upgraded to Mailman 2.1.2, so if you have > a problem with the list please let me know. > > If you post to the list and your mail does not go through, you will > need to check the subscription form at: > > http://zgp.org/mailman/listinfo/p2p-hackers > > to make sure you are subscribed from the correct address. I put the greylist spam system on my 6 Mailman lists and it works great. I probably spend 90% less time cleaning out the messages that come from non-subscribers. There's no false positive or false negative issue with this software either: http://projects.puremagic.com/greylisting/ Best, Blair -- Blair Zajac Plots of your system's performance - http://www.orcaware.com/orca/ From sean at lynch.tv Wed Aug 27 21:14:13 2003 From: sean at lynch.tv (Sean R. Lynch) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] Point of order: non-subscriber mail In-Reply-To: <3F4D0C29.17A60DAA@orcaware.com> References: <20030827165737.GA1405@zgp.org> <3F4D0C29.17A60DAA@orcaware.com> Message-ID: <1062018852.17652.31.camel@localhost> On Wed, 2003-08-27 at 12:53, Blair Zajac wrote: > I put the greylist spam system on my 6 Mailman lists and it works > great. I probably spend 90% less time cleaning out the messages > that come from non-subscribers. > > There's no false positive or false negative issue with this software > either: Ugh. Returning temporary failures to users/hosts you haven't seen before is antisocial, and it only works against spammers using misbehaving mailers. It won't do anything at all against open relay spammers and spammers who use real mail servers. Eventually, if this were widely adopted, spammers would just fix their crappy software and the cost of "greylisting" would be worse than the benefit, so people would stop using it. IMHO it's better to send *some* sort of notification to the sender that their message was rejected, even if it does end up with an innocent user or ISP; if someone is joe-jobbed, they're gonna get pummelled with crap anyway, and that's the spammer's fault, not ours. IMHO the cost of not notifying someone that their message was discarded is worse than the cost of sending one more bogus message to someone who's already in trouble. Besides, almost all of the autoresponses my lists try to send to spams end up expiring from my queue anyway. Actually, it turns out I originally sent this message from the wrong address, and I did get the "your message awaits moderator approval" message, so users will get some sort of notification that they sent from the wrong address. They just won't know that it was deleted... it'll just never get posted to the list. This is how my lists are set up as well. From blair at orcaware.com Wed Aug 27 21:25:29 2003 From: blair at orcaware.com (Blair Zajac) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] Point of order: non-subscriber mail References: <20030827165737.GA1405@zgp.org> <3F4D0C29.17A60DAA@orcaware.com> <1062018852.17652.31.camel@localhost> Message-ID: <3F4D21C9.136D081C@orcaware.com> "Sean R. Lynch" wrote: > > On Wed, 2003-08-27 at 12:53, Blair Zajac wrote: > > I put the greylist spam system on my 6 Mailman lists and it works > > great. I probably spend 90% less time cleaning out the messages > > that come from non-subscribers. > > > > There's no false positive or false negative issue with this software > > either: > > Ugh. Returning temporary failures to users/hosts you haven't seen before > is antisocial, and it only works against spammers using misbehaving > mailers. This is off topic to the list, but here goes. It also nicely prevented any issues with the recent SoBigF virus. I didn't see a single message from it. > It won't do anything at all against open relay spammers and > spammers who use real mail servers. True, but it does work. People have also reported seeing a reduction in the number of spam email attempting to get through. Just to say it does work and works nicely for me. We can take any further discussion off list. Blair -- Blair Zajac Plots of your system's performance - http://www.orcaware.com/orca/ From zooko at zooko.com Wed Aug 27 21:40:44 2003 From: zooko at zooko.com (Zooko) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] Point of order: non-subscriber mail In-Reply-To: Message from "Sean R. Lynch" of "27 Aug 2003 14:14:13 PDT." <1062018852.17652.31.camel@localhost> References: <20030827165737.GA1405@zgp.org> <3F4D0C29.17A60DAA@orcaware.com> <1062018852.17652.31.camel@localhost> Message-ID: "Sean R. Lynch" wrote: > > Actually, it turns out I originally sent this message from the wrong > address, and I did get the "your message awaits moderator approval" > message, so users will get some sort of notification that they sent from > the wrong address. They just won't know that it was deleted... it'll > just never get posted to the list. This is how my lists are set up as > well. Actually this is because I changed the default setting back to "hold for moderator approval". If another flood of spam begins, I'll turn it to "reject" (not "discard"). I decided to delay announcing this policy change until I had talked about it with the other moderator and tried it out for a bit. Since there are more than 500 subscribers to this list, I try to minimize my contribution to unnecessary list traffic. Imagine 500 people sitting in an audience listening to you ramble about decentralized incentives, self-healing DHTs, and spam management! Gulp. --Z From seanl at chaosring.org Wed Aug 27 20:09:20 2003 From: seanl at chaosring.org (Sean R. Lynch) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] Point of order: non-subscriber mail In-Reply-To: <3F4D0C29.17A60DAA@orcaware.com> References: <20030827165737.GA1405@zgp.org> <3F4D0C29.17A60DAA@orcaware.com> Message-ID: <1062014959.17652.9.camel@localhost> On Wed, 2003-08-27 at 12:53, Blair Zajac wrote: > I put the greylist spam system on my 6 Mailman lists and it works > great. I probably spend 90% less time cleaning out the messages > that come from non-subscribers. > > There's no false positive or false negative issue with this software > either: Ugh. Returning temporary failures to users/hosts you haven't seen before is antisocial, and it only works against spammers using misbehaving mailers. It won't do anything at all against open relay spammers and spammers who use real mail servers. Eventually, if this were widely adopted, spammers would just fix their crappy software and the cost of "greylisting" would be worse than the benefit, so people would stop using it. IMHO it's better to send *some* sort of notification to the sender that their message was rejected, even if it does end up with an innocent user or ISP; if someone is joe-jobbed, they're gonna get pummelled with crap anyway, and that's the spammer's fault, not ours. IMHO the cost of not notifying someone that their message was discarded is worse than the cost of sending one more bogus message to someone who's already in trouble. Besides, almost all of the autoresponses my lists try to send to spams end up expiring from my queue anyway. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://zgp.org/pipermail/p2p-hackers/attachments/20030827/0e283cd4/attachment.pgp From greg at electricrain.com Fri Aug 29 23:04:10 2003 From: greg at electricrain.com (Gregory P. Smith) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] RFC3548 is out In-Reply-To: <20030709032024.GC15571@bodin.org> References: <20030709032024.GC15571@bodin.org> Message-ID: <20030829230410.GA32166@zot.electricrain.com> Sweet! I'm glad to see that the character substitution to make base64 in URLs work that i picked "way" back in dec1999/jan2000 is finally in an RFC. :) On Wed, Jul 09, 2003 at 05:20:24AM +0200, Magnus Bodin wrote: > > Just for curiosity; RFC3548 is finally out and it has a nice little > reference to this list: > > [8] Wilcox-O'Hearn, B., "Post to P2P-hackers mailing list", World > Wide Web http://zgp.org/pipermail/p2p-hackers/2001- > September/000315.html, September 2001. > > i.e. > > > > > I have a copy of the RFC here for laziness: > > /magnus > > -- > http://x42.com > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers -- Does the name Pavlov ring a bell? From thiemann at informatik.uni-freiburg.de Sun Aug 24 10:58:18 2003 From: thiemann at informatik.uni-freiburg.de (Peter Thiemann) Date: Sat Dec 9 22:12:22 2006 Subject: [p2p-hackers] Re: draft-thiemann-hash-urn-00 References: <20030818110317.GC5488@fysh.org> Message-ID: >>>>> "zefram" == zefram writes: zefram> draft-thiemann-hash-urn-00 specifies that SHA-1 hashes are to be zefram> encoded in base32, but the example you give shows base16 encoding. zefram> Furthermore, the text specifying the use of base32 says the encoded hash zefram> value "consists of 20 BASE32DIG"; this is inconsistent with the later zefram> description of base32 encoding that requires padding of zefram> the encoded data. Thanks for the observation, I'll fix it. zefram> I wonder whether defaulting the hash scheme (to SHA-1) is really any more zefram> useful than it is unclear. A few years ago, the default hash scheme (in zefram> people's minds) was MD5; now it's SHA-1; in a few years it could well be zefram> SHA-256 or SHA-512 (which have already been defined). I suggest that zefram> in ten years almost all hash URNs being generated will need the hash zefram> scheme explicitly specified, so we don't win much by having a default. zefram> Rather, the effect of the default will be to make the meaning of such zefram> hash URNs unclear, especially when the default scheme becomes an obscure zefram> historical relic. We're seeing the very beginning of this problem now zefram> with systems that made MD5 the default. My original ID for this namespace (appended) allowed for variation in the hash scheme for exactly the reasons that your are mentioning. However, during the discussion of that ID a preference emerged to hardwire the schemes into the namespace definition. The following concerns were articulated (quotes from the discussion, see the URN NIDs mailing list archive at http://lists.research.netsol.com/pipermail/urn-nid, the relevant postings are in 2003-July) * I don't like the idea of making 'hash-scheme' extensible. It's not "easy" to add a new hash scheme, because old software would have to be updated. * there will be different ids for the same resource-- impractical when you try to look it up under one id, but it's stored under another * In order to avoid chosen-algorithm attacks, the set of standardized hashes should be kept very small and directly under the control of the IETF and at the guidance of the CFRG. By having it as a top level URN scheme such as urn:sha1, implementors will tend to focus on the algorithm itself rather than the notion of generic hash-based naming. * We must avoid having a generic hash name space that allows developers to add new hashes willy-nilly. I believe that many non crypto-savvy developers would tend to support every algorithm specified in the name space without understanding that by supporting multiple agorithms you introduce a weakest-link condition. There are certainly arguments in either direction. My conclusion from the discussion is to hardwire a chosen set of hash schemes into the namespace definition. If another hash scheme emerges as the de facto standard or if one of the hash schemes becomes broken, then it will be easy to post a revised namespace definition to add or remove hash schemes. [Of course, this does not preclude anyone from ignoring the namespace definition and use it in whatever way they please.] zefram> While we're on defaulting, the media type: it seems more useful to me to zefram> say that the default is that the media type is simply not specified by zefram> the hash URN. This is particularly useful if the application generating zefram> the URN doesn't know the media type (all too common). An application zefram> reading a URN that doesn't specify media type may still be able to find zefram> out the media type itself from other sources, or make reasonable guesses, zefram> possibly based on contextual information that was not available to the zefram> URN generator. Forcing application/octet-stream handling in the absence zefram> of specific knowledge is unwise. My reading of the definition of application/octet-stream covers exactly the case were the actual media type is not known and it's up to the application to figure out what to do with it. To quote from RFC2046, sec 4.5.1: The "octet-stream" subtype is used to indicate that a body contains arbitrary binary data. [...] The recommended action for an implementation that receives an "application/octet-stream" entity is to simply offer to put the data in a file, with any Content-Transfer-Encoding undone, or perhaps to use it as input to a user-specified process. -Peter -------------- next part -------------- Network Working Group P. Thiemann Internet-Draft Freiburg University Category: Informational 20 June 2003 Expires: December 20, 2003 A URN Namespace For Content-Based Unique Identifiers draft-thiemann-cbuid-urn-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 31, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes a URN namespace to identify immutable octet- stream resources using content-based unique identifiers. The naming scheme relies on an algorithm that computes identifiers from media types and cryptographic hashes without a central authority. 1. Conventions used in this document The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. Thiemann [Page 1] Internet-Draft Content-Based Unique Identifiers 30 June 2003 2. Introduction A URN serves as a unique name for a resource [RFC1630]. Most URN namespaces involve a central authority to ensure uniqueness of assigned names. This approach has its merits but it requires organizational structures for processing requests for naming and for bookkeeping about used names. Thus, acquiring a URN becomes an involved task not to be undertaken on a day-to-day basis. The cbuid proposal enables using and creating URNs on a day-to-day basis for storing and retrieving immutable octet-stream resources. It relies on a decentralized, algorithmic assignment of identifiers by exploiting the uniqueness guarantees of (cryptographic) hashes. In fact, this document contains the assignment algorithm so that everyone can generate identifiers in this namespace. The namespace has two subspaces, an untyped one and a typed one. The untyped subspace considers the referenced resource as a sequence of octets and computes the hash directly from that representation. The typed subspace relies on the media type of the resource to compute one or more hashes depending on the structure of the resource. At present, a special typed subspace is only defined for the media types application/octet-stream and message/rfc822. This namespace specification is for a formal namespace. The specification adheres to the guidelines given in "Uniform Resource Names (URN) Namespace Definition Mechanisms" [RFC3406]. 3. Specification Template Namespace ID: "cbuid" requested. Registration Information: Registration Version Number: 1 Registration Date: 2003-06-?? Declared registrant of the namespace: The CBUID Project Institut fuer Informatik Universitaet Freiburg Georges-Koehler-Allee 079 D-79110 Freiburg Germany Thiemann [Page 2] Internet-Draft Content-Based Unique Identifiers 30 June 2003 Contact: Peter Thiemann info@www.cbuid.org Declaration of syntactic structure: The Namespace Specific Strings (NSS) of all URNs assigned by the schema described in this document will conform to the syntax defined in section 2.2 of RFC2141 [RFC2141]. The formal syntax of the NSS is defined by the following normative ABNF [RFC2234] rules for : cbuid-nss = type-spec ":" hash *1(":" type-specific-extension) type-spec = "*" / media-type *parameter parameter = ";" "mode" "=" 1*DIGIT / ";" token "=" token token = 1*(ALPHA / DIGIT) hash = hash-scheme ":" hash-value *("/" hash-value) hash-scheme = "md5" / "sha1" / "hash127" / hash-token hash-token = token hash-value = "*" / 1*HEXDIG The following are comments and restrictions not captured by the above grammar. A is any MIME media type [RFC2046] which is registered in the appropriate IANA registry [IANA-MT]. A is a pair of a parameter name and a parameter value. If the parameter name is "mode" then the parameter value is a string of digits. A is an alphanumeric token. A may be "*" (unspecific) or it is a non-empty sequence of hexdigits whose value as a sequence of bits must be a valid hash for the specified hash-scheme. If hash-scheme is "md5" or "hash127", then each specified hash-value consists of 32 HEXDIG. If hash- scheme is "sha1", then each specified hash-value consists of 40 HEXDIG. The "mode" parameter MUST specify the number of additional s. Its value defaults to 0 if the parameter is omitted. That is, mode=0 (or mode parameter omitted) means that there is one , for mode=1 there are two s, and so on. If the type specification is "*" (unspecific), then the hash part MUST specify exactly one , the "mode" parameter MUST be 0, and there MUST NOT be a . If a type is specified, then more than one MAY BE given, the "mode" parameter MUST specify the number of extra s, and a MAY BE allowed. If an identifier contains only one , then this MUST NOT be "*" (unspecific). Examples: urn:cbuid:*:md5:5307d294b6ccd9854f2deed8c1628b72 urn:cbuid:*:sha1:7660c8efbe7f656ce7612636c83a138c085bad3f urn:cbuid:message/rfc822:md5:5307d294b6ccd9854f2deed8c1628b72 urn:cbuid:message/rfc822;mode=1:md5:* /d97a43ed7125019c363b00bd27411fa7 urn:cbuid:message/rfc822;mode=1:md5 :b260fb53d7ec3b530e5a6332763a2bfb /d97a43ed7125019c363b00bd27411fa7 In the last two examples, the linebreak and whitespace before the ":" and the "/" are inserted for editorial reasons, they are not part of the URN. Relevant ancillary documentation: None as yet. Identifier uniqueness considerations: Each identifier contains at least one cryptographic hash value for the referenced resource. The probability that two different resources have the same hash value depends on the hash function. For the md5 hash where the hash value has 128 bits, it is conjectured [RFC1321] that the probability of a collision is in the order of 1/2^64. For the sha1 hash where the hash value has 160 bits, this probability should be even smaller. In addition, if a procedure for creating collisions with one of these hash functions is found, then it is easy to extend the "cbuid" NSS with hash functions that provide smaller collision probabilities. Identifier persistence considerations: Thiemann [Page 4] Internet-Draft Content-Based Unique Identifiers 30 June 2003 The binding between the identifier and the referenced resource is permanently established by the assignment algorithm that computes the identifier from the resource. Process of identifier assignment: Assignment is completely open, following the algorithm below. The inputs of the algorithm are - the name of a hash function - a media type for - a mode parameter (0 if omitted) - a resource (a sequence of octets) The algorithm applies the hash function to the resource, converts the resulting bit sequence into a sequence of hexdigits, and constructs the URN from the type-spec, the mode, the hash-scheme, and the sequence of hexdigits using the syntax described above. Algorithms for the predefined hash functions are defined in the following references: md5 [RFC1321] sha1 [RFC3174] hash127 [HASH127] The conversion of a to a string proceeds as follows. The bits in the are converted from most significant to least significant bit, four bits at a time to their ASCII presentation. Each sequence of four bits is represented by its hexadecimal digit from "0123456789abcdef". That is, binary 0000 gets represented by the character '0', 0001, by '1', and so on up to the representation of 1111 as 'f'. For a resource of type "message/rfc822", the mode parameter MAY be 1. In this case two hash values are requested. The algorithm computes separate hash-values for the header and the body of the message and constructs the identifier by concatenating the , the mode parameter, the , and the two s (hash of header, heash of body) according to the syntax described above. [Note: no unspecific hash-values are generated by the algorithm, they are only used in queries.] At present, mode MUST be 0 for any other type. Process of identifier resolution: Thiemann [Page 5] Internet-Draft Content-Based Unique Identifiers 30 June 2003 The cbuid namespace is intended for communication between a group of clients and a repository (for example, an email client and an email store in which identifiers would replace the UID mechanism of IMAP [RFC2060]). Since the repository keeps all available resources, it implements the mechanism outlined below for resolution. In the present stage, global resolution is not intended. However, this might become sensible in a later revision, after experience has been gained. A local resource repository maintains a mapping from and to resources. From that information it evaluates identifiers as follows. If an identifier contains only one (specific) hash-value, then it refers to the entire resource determined by the repository's mapping. The mediatypes "application/octet-stream" and "message/rfc822" have fixed type-specific interpretations. The mediatype "application/octet-stream" is equivalent to "*" (unspecific). It can only have one and refers to the entire resource determined by the repository's mapping. If the mediatype is "message/rfc822", then the mode parameter may be used to select an alternative resolution. The permitted values for mode are 0 and 1. Mode=0 selects the standard resolution as for "application/octet-stream". If mode=1, then two s must be supplied. The first is the result of applying the hash to the header of the message (including the CRLF terminating the last field but without the blank line separating header from body). It MAY be unspecific. The second is the result of applying the hash function to the body of the message. It MUST be specific. (See [RFC2822] for the precise definitions.) If both hash- values are specific, then one specific message is referenced. If only the body hash is specific, then the body is returned with a minimal anonymized header where all fields that may contain personal information are blanked out. More specifically, the Date field remains, the From, To, and Subject fields remain but are blanked out, the MIME header fields remain unchanged [RFC2045], but all further header fields are removed from the header. For the mediatype "message/rfc822", a MAY be present for selecting parts of a message. In this case, the syntax for is given by the non- Thiemann [Page 6] Internet-Draft Content-Based Unique Identifiers 30 June 2003 terminal from the specification of the IMAP URL scheme [RFC2192]. For illustration, here is a review and interpretation of the examples given above. urn:cbuid:*:md5:5307d294b6ccd9854f2deed8c1628b72 urn:cbuid:*:sha1:7660c8efbe7f656ce7612636c83a138c085bad3f Both are references to an untyped resource using the hash value of the entire resource. Their mode parameter is (implicitly) 0. urn:cbuid:message/rfc822:md5:5307d294b6ccd9854f2deed8c1628b72 A reference to an entire email message. urn:cbuid:message/rfc822;mode=1:md5:* /d97a43ed7125019c363b00bd27411fa7 A reference to an anonymized message. Mode=1 indicates that there are two hash values present. [Note: the linebreak and whitespace before the "/" is inserted for editorial reasons, it is not part of the URN.] urn:cbuid:message/rfc822;mode=1:md5 :b260fb53d7ec3b530e5a6332763a2bfb /d97a43ed7125019c363b00bd27411fa7 A reference to an entire email message by header and body hashes. [Note: the linebreak and whitespace before the ":" and the "/" are inserted for editorial reasons, they are not part of the URN.] Rules for Lexical Equivalence: Lexical equivalence is identity after normalization. An identifier in the cbuid URN namespace is nomalized by 1. converting all characters to lower case 2. eliminating the parameter "mode" if its value is 0 3. eliminating all parameters which are not "mode" parameters. Conformance with URN Syntax: There are no additional characters reserved. Thiemann [Page 7] Internet-Draft Content-Based Unique Identifiers 30 June 2003 Validation mechanism: Each identifier in the namespace MUST conform with the syntax specified above. Unknown parameters MUST be ignored. Scope: The namespace is global and public. 4. IANA Considerations This document includes a URN namespace registration that is to be entered into the IANA registry for URN NIDs. 5. Namespace Considerations Most URN namespaces are assigned to organizations and rely on a centralized registry to achieve uniqueness and persistency. In contrast, the cbuid namespace is not tied to any organization. Assignment of identifiers can be performed and verified individually, while uniqueness is still preserved (with a probability close to 1). Moreover, the naming scheme is extensible with respect the addressing requirements of new mediatypes and with respect to improved hash functions. The transition between hash functions does not mean that the "old" identifiers loose their meaning (cf. the discussion in BCP 66 [RFC3406]). However, each resolver implementation will prefer one hash scheme over the other and will resolve identifiers based on the preferred scheme more quickly. The resources managed by the cbuid namespace are immutable octet streams. The only meaningful services are storage and retrieval, as provided by a repository. There is no update operation. 6. Community Considerations We expect to make public implementations of tools available that manage repositories of email messages and other immutable resources. Addressing of resources in these repositories will rely on cbuid URNs. The main impact that we expect from the use of cbuid URNs is sharing of resources among the users of a single repository. Once a distribution scheme has been devised (perhaps also on the basis of the URNs), repositories may be replicated and the benefit of sharing may be exploited further. Thiemann [Page 8] Internet-Draft Content-Based Unique Identifiers 30 June 2003 7. Security Considerations As long as access to a repository is regulated by a suitable form of access control and transport encryption, there are no security considerations inherent in the use of cbuid URNs. If unregulated access (e.g., without authentication) to a repository is allowed, then only anonymized accesses should be permitted (as defined for the message/rfc822 type) to protect the privacy of the registered clients of the repository. Normative References [HASH127] Bernstein, D. J., "Floating-Point Arithmetic and Message Authentication", http://cr.yp.to/papers/hash127.ps, March 2000. [RFC1321] Rivest, R. L., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC2045] Freed, N., and Borenstein, N., "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2046] Freed, N., and Borenstein, N., "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. [RFC2192] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997. [RFC2234] Crocker, D., Editor, and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC2822] Resnick, P., Editor, "Internet Message Format", RFC2822, April 2001. [RFC3174] Eastlake, E., and Jones, P., "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001. Informational References [IANA-MT] IANA Registry of Media Types: ftp://ftp.isi.edu/in- notes/iana/assignments/media-types/ [RFC1630] Berners-Lee, T., "Universal Resource Identifiers in WWW," RFC 1630, June 1994. Thiemann [Page 9] Internet-Draft Content-Based Unique Identifiers 30 June 2003 [RFC2060] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, December 1996. [RFC3406] Daigle, L., van Gulik, D.W., Iannella, R., and Faltstrom, P., "Uniform Resource Names (URN) Namespace Definition Mechanisms", RFC 3406, October 2002. Contributors Stephanie Kollenz Matthias Neubauer Author's Address Peter Thiemann Institut fuer Informatik Universitaet Freiburg Georges-Koehler-Allee 079 D-79110 Freiburg Germany Phone: +49 761 203 8051 EMail: thiemann@acm.org URL: http://www.informatik.uni-freiburg.de/~thiemann Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Thiemann [Page 10] Internet-Draft Content-Based Unique Identifiers 30 June 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Thiemann [Page 11]