From c.tavoularis@utoronto.ca Mon Nov 19 12:53:53 2001 Received: from bureau6.utcc.utoronto.ca (bureau6.utcc.utoronto.ca [128.100.132.16]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fAJHrqR13506 for ; Mon, 19 Nov 2001 12:53:53 -0500 (EST) Received: from webmail2.ns.utoronto.ca ([128.100.132.25] EHLO webmail2.ns.utoronto.ca ident: IDENT-NOT-QUERIED [port 48358]) by bureau6.utcc.utoronto.ca with ESMTP id <238526-4416>; Mon, 19 Nov 2001 12:53:41 -0500 Received: by webmail2.ns.utoronto.ca id <24411-13842>; Mon, 19 Nov 2001 12:53:28 -0500 To: egs@CS.Cornell.EDU Subject: 615 PAPER 60 Message-ID: <1006192401.3bf947119e702@webmail.utoronto.ca> Date: Mon, 19 Nov 2001 12:53:21 -0500 (EST) From: c.tavoularis@utoronto.ca MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.3 This paper proposes the Freenet network application to store files and allow users to access files privately and completely unaware of physical location. Freenet behaves as an adaptive peer-to-peer system that uses a network of identical nodes for storage and routing to avoid central points of failure or attack. Freenet dynamically creates replicas of files near the requestors and removes files in areas where they are no longer needed. Freenet operates as a peer-to-peer system where nodes request a file store or retrieve service to their immediate neighbors using a location-independent naming key. Requests are forwarded hop-by-hop similar to IP routing and have a limited hops-to-live as well as a unique random id number to avoid loops in routing. Each node has a data store to which it must allow network access, as well as a dynamic routing table with keys associated with node addresses. File keys are generated using hash functions. Each file has a random public/private key pair to serve as a namespace called a signed-subspace key (SSK) and a keyword-signed key (KSK) generated by short descriptive text. A user will publish his descriptive string and subspace public key, which maintaining his private key so no one can add files to his subspace. A content-hash key is useful for updating and splitting of files since the old version of the file remains temporarily available while a new version is been added to the system. There is more than one solution proposed to search for keys, including insertion of indirect files by users with pointers to the real files, and publicizing of public key compilations by users. Once the file key is known, a user will ask its node to retrieve the file. This node will check it’s own data store, and use its routing table to forward the request to a neighboring node if it does not have a copy of the file. Requests propagate as a steepest-ascent hill-climbing search with backtracking until the file is found or the request times out. A similar search is performed to insert new files. Similar keys are located and success is returned if the hops-to-live is reached without any collisions. Essentially, a trend is supposed to form where nodes become experts on similar keys located on the same node, and caching brings copies of files closer to the requestor. When the system starts running out of storage, the least recently used files are replaced. Security in the system is achieved by enforcing anonymous requestors and senders, as well employing a cryptographic protocol to add new nodes to the system. Freenet provides redundancy, privacy and robustness to central points of failure. Freenet’s performance converges over time to reduce path length request. It would perform less impressively if a file is frequently being updated such that large amounts of overhead is created, and cached data will easily become stale as well as the information in routing tables. In this case, the fact that there are mirrored copies closer to the requestor is irrelevant and the search mechanism becomes inefficient. Also, it is not clear what happens if a user specifically wants to remove his file. From eyh5@ee.cornell.edu Mon Nov 19 17:54:26 2001 Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fAJMsQR07878 for ; Mon, 19 Nov 2001 17:54:26 -0500 (EST) Received: from photon.ece.cornell.edu (photon.ece.cornell.edu [128.84.81.138]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id fAJMqQM09946 for ; Mon, 19 Nov 2001 17:52:26 -0500 Date: Mon, 19 Nov 2001 17:52:33 -0500 (EST) From: Edward Hua X-X-Sender: To: Subject: 615 Paper # 60 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Freenet: A Distributed Anonymous Information Storage and Retrieval System Ian Clark, Oskar Sandberg, Brandon Wiley, and Theodore W. Hong This paper presents Freenet, an adaptive peer-to-peer network application that permits the publication, replication, and retrieval of datawithout compromising the anonymity of both the authors and readers of information. The Freenet project bears in mind five design objectives: 1)Anonymity for both producers and clients of infomration 2)Deniability for storers of information 3)Resistance to attempts by third parties to deny access to information 4)Efficient dynamic storage and routing of information 5)Decentralization of all network functions. The idea of Freenet was conceived in response to the threats of on-line theft, attack, and evesdropping of information. In a Freenet architecure, requests for keys are passed from node to node through a chain of proxy requests in which each node makes a local decision as to where to send the request next. The routing algorithms for storing and retrieving data are designed to adaptively adjust routes over time to provide efficient performance while using only local knowledge. The operations of Freenet can be broken down to several functions, including keys and searching, data retrieval, data storage, data management, and node addition. Keys and searching allows the user to identify intended data by binary file keys obtained by applying the SHA-1 hashing hunction; data retrieval is regulated by hops-to-live constraint and the loop-avoidance condition. It may also have the potential benefits of allowing the node hoding the requested data to be more experienced in handling incoming requests if these requests are of similar key. Data storage refers to a node posting and advertising new information under the hops-to-live constraint. Data management does not keep permanent copies of data files, but instead flushs out the least recently used files in order to make room for the new addition of files. Also for a variety of reasons, the node operator does not have to explicitly know the content of their datastores. Node addition is achieved by a new node announcing its presence to its neighboring nodes. In so doing, a cryptographic protocol is employed to allow existing nodes to be consistent with each other in deciding which keys to send to the new node. The performance of Freenet is evaluated in four aspects: network convergence, scalability, fault tolerance, and security. Freenet is able to achieve quick network convergence within a shor period of time while maintaining a suitable number of imtermediate hops for a path after convergence. The network scales rather well for the median and third quartile in that as the network size grows, the request pathlength remains relatively constant over a large network expansion. The authors of the paper also show that a Freenet architecture is able to sustain an acceptable fault tolerance even when up to 30% of nodes have failed in the network. Finally in dealing with the issue of security, the authors claim that although the basic Freenet does not offer much of protection against malicious users of various forms, when coupled with pre-routing, Freenet is successful in protecting sender anonymity and key anonymity beyond suspicion. However, judging from the Table 1 presented in the paper, I do not share this claim, as its shows the basic Freent is only able to hide, beyond suspicion, the sender anonymity from a group of collaborating nodes, and all three other scenarios (sender and key anonymity with a local eavesdropper and key anonymity with collaborating nodes) show the identities of the sender and receiver of data easily fall prey to the attackers. From andre@CS.Cornell.EDU Tue Nov 20 00:24:08 2001 Received: from postoffice.mail.cornell.edu (postoffice.mail.cornell.edu [132.236.56.7]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fAK5O8R09277; Tue, 20 Nov 2001 00:24:08 -0500 (EST) Received: from khaffy (d7b098.dialup.cornell.edu [128.253.157.98]) by postoffice.mail.cornell.edu (8.9.3/8.9.3) with ESMTP id AAA25568; Tue, 20 Nov 2001 00:24:06 -0500 (EST) Received: from andre by khaffy with local (Exim 3.22 #1 (Debian)) id 165xnm-0001q5-00; Tue, 20 Nov 2001 00:26:10 +0100 Date: Tue, 20 Nov 2001 00:26:10 +0100 From: =?iso-8859-1?Q?Andr=E9?= Allavena To: egs@CS.Cornell.EDU Cc: andre@CS.Cornell.EDU Subject: 615 PAPER 60 Message-ID: <20011120002610.A7063@khaffy> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.3.18i Sender: =?iso-8859-1?Q?Andr=E9_Allavena?= Freenet - A peer-to-peer network daemon with anonymity Debian abstract: Freenet is a peer-to-peer network designed to allow the distribution of information over the Internet in an efficient manner, without fear of censorship. Freenet is completely decentralized, meaning that there is no person, computer, or organisation in control of Freenet or essential to its operation. This means that Freenet cannot be attacked like centralized peer-to-peer systems such as Napster. Freenet also employs intelligent routing and caching meaning that it learns to route requests more efficiently, automatically mirrors popular data, makes network flooding almost impossible, and moves data to where it is in greatest demand. All of this makes it much more efficient and scalable than systems such as Gnutella. For more info see http://www.freenetproject.org/ It is the first time I see a paper written by people from so many different (and so far away) places. Freenet made it to Debian's woddy and I presume to other Linux distribution, which means it is a sucess. I didn't test it though. I think it is a very good system. Privacy is so weak now, this is defending it. I think Freenet has the potential to be spread out on a large scale. It consumes more bandwith and more storage place than conventional storage systems, but storage is not an issue anymore, and bandwith not often, and should not be one for long. This raises of course the issue of software piracy and underage porngraphy, because it makes it much more difficult to track down. The fact that there is a TTL value make the system weaker in some sense: given a set of presumable stored files by a node, requesting them with a TTL of 1 allows with a high probability to say if this nodes stores a susbsantial subset of this files. But do we care? My question is: can such an attack be made with a TTL of say 4? One could envisage to change the TTL counter to a time based value, and either assume that processing time is random, or add a random delay of the order of magnitude of the processing delay. -- André Allavena (local) 154 A Valentine Place École Centrale Paris (France) Ithaca NY 14850 USA Cornell University (NY) (permanent) 879 Route de Beausoleil PhD in Computer Science 06320 La Turbie FRANCE From daehyun@csl.cornell.edu Tue Nov 20 11:12:47 2001 Received: from wilkes.csl.cornell.edu (wilkes.csl.cornell.edu [132.236.71.69]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fAKGClR25407 for ; Tue, 20 Nov 2001 11:12:47 -0500 (EST) Received: (from daehyun@localhost) by wilkes.csl.cornell.edu (8.9.3/8.9.2) id LAA59342 for egs@cs.cornell.edu; Tue, 20 Nov 2001 11:12:42 -0500 (EST) (envelope-from daehyun) From: Daehyun Kim Message-Id: <200111201612.LAA59342@wilkes.csl.cornell.edu> Subject: 615 PAPER 60 To: egs@CS.Cornell.EDU Date: Tue, 20 Nov 2001 11:12:42 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit This paper proposes a distributed information storage and retrieval system called Freenet. Freenet is distributed - there is no broadcast and no centralized location index and files are location independent. And Freenet is anonymous - it is impossible to discover the true origin and destination of files passing through the network. Freenet is implemented as an adaptive peer-to-peer network of nodes that query on another to store and retrieve data files. Each node maintains its own local datastore and dynamic routing table. A requests for data file (location independent key) is passed along from node to node through a chain of proxy requests in which each node makes a local routing decision. Each request is given hops-to-live (similar to TTL) to prevent infinite chain and pseudo-unique random identifier to prevent loop. A request is routed throu the network until it is either satisfied or exceeds its hops-to-live limit. Then the success or failure results is passed back to the sender. Files are identified by file keys obtained by applying a hash function. There are three types of file keys, keyword-signed key (KSK), signed-subspace key (SSK) and content-hash key (CHK). For the file searching purpose, indirect files are used. To retrieve a file, user sends a request specifying the file key and a hop-to-live. Then the message is routed through the networks and finally the results is returned to the user. For the security concern, any node along the route can change the data source of the reply message. To insert a file, user also sends a request. First the file key is searched in the same way as retrieval. If there already exists the same file key, it is returned for the user to try a different key. Otherwise, a success message is returned and the user send the data for nodes to insert a new entry. For the finite storage capacity, Freenet uses LRU. If the storage runs short, the least recently used files are evicted in order until there is room. A node joins the network by sending a announcement message with a random key. When a already joined node receives it, the node generates another random key, XORs it with the key received and propagates the announcement. This procedure repeats until hops-to-live runs out. Freenet protocol is packet-oriented and uses self-contained messages. Each messages contain a transaction ID, a hops-to-live and a depth. In my opinion, Freenet has a high potential. It seems scalable and robust. Most of all, its security feature might be getting more important in the future network environments. But, there are several points I couldn't understand. First, how to guarantee that a useful file may not deleted. As far as I understand, it is possible for a file to be deleted from all the nodes. Seconde, how to guarantee the consistency between two files with the same key. If a node tries to insert a key and another node out of hops-to-live limit has the same key, it seems to me possible that two node can have different files with the same key. From ramasv@CS.Cornell.EDU Tue Nov 20 11:48:21 2001 Received: from exchange.cs.cornell.edu (exchange.cs.cornell.edu [128.84.97.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fAKGmLR01803 for ; Tue, 20 Nov 2001 11:48:21 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: cs615 PAPER 60 Date: Tue, 20 Nov 2001 11:48:21 -0500 Message-ID: <706871B20764CD449DB0E8E3D81C4D4301E7F295@opus.cs.cornell.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: cs615 PAPER 60 Thread-Index: AcFx4ymW4XfWEAZNTguMiNPbISS/5w== From: "Venu Ramasubramanian" To: "Emin Gun Sirer" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sundial.cs.cornell.edu id fAKGmLR01803 FREENET: A Distributed Anonymous Information Storage and Retrieval System. This paper presents an architecture for a robust and anonymous completely distributed information storage and retrieval system. This is a peer-peer system that distributes data throughout the internet on nodes willing to participate. The features that make this system very interesting are sender and receiver anonymity, failure robustness, absence of any centralization and ability to scale. Data (file) in this system is identified by means of a key that is a hash of the data name. An asymmetric key pair is generated from this name that serves to authenticate the data. The data is further encypted by key that is obtained by hasing the contents. While the data creators can easily compute the data, it is a mystery how a node in need of data would be able to obtain the keys for the corresponding data. It is also further required that the requestor obtain the key without exposing itself to the world and also without knowing the sender. Although there is a proposal in the paper on how to do this, they do not elaborate this further and hence does not seem to be a part of their system. The routing protocol however, looks real neat. More data is distributed in the network as more and more requests keep getting generated. The idea of caching data of similar keys close together greatly eases the overhead on the routing protocol. Making the data inserts in a way identical to data requests is cute and effective. The requests are tagged with a TTL field and the protocol depends on the obscurity of this field to prevent sender and receiver anonymity. However it appears that a long term analysis of network activity around a requestor might raise suspicions. The routing protocol also does not attempt to balance the load across intermediate nodes. On the whole, this is a very interesting idea. Lot's of people would be pleased with sender and receiver anonymity. From viran@csl.cornell.edu Tue Nov 20 11:57:06 2001 Received: from moore.csl.cornell.edu (moore.csl.cornell.edu [132.236.71.83]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fAKGv6R03122 for ; Tue, 20 Nov 2001 11:57:06 -0500 (EST) Received: from localhost (viran@localhost) by moore.csl.cornell.edu (8.11.3/8.9.2) with ESMTP id fAKGv0Z89397 for ; Tue, 20 Nov 2001 11:57:00 -0500 (EST) (envelope-from viran@moore.csl.cornell.edu) X-Authentication-Warning: moore.csl.cornell.edu: viran owned process doing -bs Date: Tue, 20 Nov 2001 11:57:00 -0500 (EST) From: "Virantha N. Ekanayake" To: Subject: 615 Paper 60 Message-ID: <20011120115305.P86337-100000@moore.csl.cornell.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Freenet is a peer-to-peer network application that provides anonymity to data sharing. Data is distributed and dynamically replicated depending on demand. Each file is identified by a key which is generated by hashing its descriptive name, another key for the file's personal namespace, and a content key based on hashing the entire file's content. The files cluster based on the similarity of the generated hash. Naturally, this precludes any type of semantic clustering, possibly obviating any type of locality in data references. Then again, it also makes the system more distributed, because related data won't be clustered around a single point of failure. The node specialization could be a drawback -- it sort of contradicts the authors argument that all nodes are equal; it's more of a constitutional "all nodes are created equal" and after that they become more diverse. A very specialized node dropping out could result in a lot of aimless network behavior until the routing tables get updated. I also wonder how one can do meta-data searches, since files are only identified by hashes based on the name. It seems you would need some sort of centralized directory of plaintext names of files in order to know what exactly is available on the network. From samar@ece.cornell.edu Tue Nov 20 13:44:03 2001 Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fAKIi3R22856 for ; Tue, 20 Nov 2001 13:44:03 -0500 (EST) Received: from aquinas.ee.cornell.edu (aquinas.ee.cornell.edu [128.84.236.57]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id fAKIftM32215 for ; Tue, 20 Nov 2001 13:41:55 -0500 Date: Tue, 20 Nov 2001 13:42:43 -0500 (EST) From: Prince Samar X-Sender: samar@aquinas.ee.cornell.edu To: egs@CS.Cornell.EDU Subject: 615 PAPER 60 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Freenet: A Distributed Anonymous Information Storage and Retrieval System The paper presents an adaptive peer-to-peer system that enables the storage and retrieval of data while maintaining the anonymity of readers and authors. The system does not any central point of failure and provides privacy to the users of the system. Other design goals of Freenet deniability for storers of information, resistance to third denial of access, efficient storage and routing and decentralization of all network functions. It is assumed that most of the nodes will run nodes, offering datastore space to the network. Each node in Freenet maintains its own local datastore on which the network is permitted to read and write. The nodes also maintain a dynamic routing table containing the addresses of other nodes and the keys that they are known to hold. Requests for keys are passed along from node to node through a chain of proxy requests in which each node makes a local decision about where to send the request next, depending on which node's key is found to be lexicographically close to the data request at hand. Files are identified by binary has keys obtained by applying a hash function. Three different types of file keys are used. The Keyword-Signed Key (KSK) is derived from a short descriptive text chosen by the user. The Signed-Subspace Key (SSK) enables personal name-spaces by randomly generating a private/public key pair that identifies the name-space of the user. The third key is the Content-Hash Key (CHK) which is derived by hashing the actual contents of the corresponding file. A request to retrieve data operates as a steepest-ascent hill-climbing search with backtracking, along with a hops-to-live limit. This has the problem of being inefficient and slow to start. The actual path taken by the request may be way off the minimum hop route, and may possibly cause congestion. However it is hypothesized that as time progresses, nodes become specialized in certain types of data, having good knowledge of data with *keys* similar to each other. Nodes can override large hops-to-live values and can forget about pending requests after a period of time. Node storage is managed as Least Recently Used (LRU) cache in which data items are kept sorted in decreasing order by time of most recent request. This has the disadvantage of a file being lost forever from the system if not used for a long time - there is no "permanent" copy of the file in Freenet. The performance analysis shows that the request path-length starts off really badly, but ultimately converges to better values. The system seems to have decent scalability and fault tolerance. Freenet provides sender anonymity beyond suspicion in the presence of collaborating nodes. Using pre-routing with Freenet also provides key anonymity beyond suspicion in the presence of a local eavesdropper. The idea of nodes getting specialized is pretty interesting as it makes routing more efficient. However, it also makes network vulnerable to failure of nodes with specialization in a particular kind in the sense that it can disrupt the routing for at least some time until new routing table entries are created. From papadp@ece.cornell.edu Thu Nov 29 03:34:21 2001 Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fAT8YLT13168 for ; Thu, 29 Nov 2001 03:34:21 -0500 (EST) Received: from kiki.ece.cornell.edu (kiki.ece.cornell.edu [128.84.83.13]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id fAT8VSM10113; Thu, 29 Nov 2001 03:31:28 -0500 Date: Thu, 29 Nov 2001 03:37:36 -0500 (EST) From: "Panagiotis (Panos) Papadimitratos" To: Emin Gun Sirer cc: Panagiotis Papadimitratos Subject: 615 PAPER 60 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Review of: "Herald: aChieving a Global Event Notification Service," by L.F. Cabrera, m.B.Jones, M. Theimer Panagiotis Papadimtratos papadp@ece.cornell.edu The authors present a hybrid of a position paper and a list of design directions and goals for a distributed, scalable event notification scheme. The basic concept that provides for the distribution of the system is the 'Rendez-vous point' (RVP) and differentiates this design from other centralized messaging/event notification services. In addition, simplicity, traded for guarantees on the notification delivery, is a major goal for the system that targets global deployment. Herald servers are to reside in numerous machines and publisher and subscriber client processes create and communicate throught the RVP's. Clients create RVP's, events are published and the RVP notifies the subcribed processes for corresponding newly published events. RVP's may be replicated and reside in different Herald machines in order to increase fault tolerance. Soft state is maintained in each RVP (i.e., state becomes obsolete unless explicitly updated) via 'time contracts' and the 'history' is proposed as a means to deal with periods of disconnection and loss of state. The extreme flexibility in the creation of RVP's and the absence of any naming scheme raises the issue of resource location; is this the reason for their proposing the use of agents as the a way to retrieve notifications (with administrative RVP's also dealing with changes)? The replication could indeed contribute to load balancing and thus scaling, but this would also require an explicit way for subscribers to switch from one replica to another, which is not straightforward at all, especially because processes that are assumed to act autonomously have to motivated to do so. Finally, the claim about 'mutually untrusted domains' recurs but apart from a generic statement about Access control policies to be employed (by herald servers? at RVP's?) there is no further explanation on how this parameter is taken into account in the design (or is it merely a re-phrasing of 'open, distributed system'?)