TWiki Home TWiki . IT . ICSI (r1.1 vs. r1.3) TWiki webs:
BG| DE | ES | FI | FR | Glossary | HU | IT | JA | Know | Main | NL | PT | Pub | RU | SL | TWiki | Test | ZH-CN? | ZH-TW? |
IT . { Home | Changes | Index | Search | Go }
 <<O>>  Difference Topic ICSI (r1.3 - 02 Feb 2002 - MarcoCalamari)
Changed:
<
<

Architecture

>
>

Architettura

Changed:
<
<

Freenet is implemented as an adaptive peer-to-peer network of nodes that query one another to store and retrieve data files, which are named by location-independent keys. Each node maintains its own local datastore which it makes available to the network for reading and writing, as well as a dynamic routing table containing addresses of other nodes and the keys that they are thought to hold. It is intended that most users of the system will run nodes, both to provide security guarantees against inadvertently using a hostile foreign node and to increase the storage capacity available to the network as a whole.

The system can be regarded as a cooperative distributed filesystem incorporating location independence and transparent lazy replication. Just as systems such as distributed.net[15] enable ordinary users to share unused CPU cycles on their machines, Freenet enables users to share unused disk space. However, where distributed.net uses those CPU cycles for its own purposes, Freenet is directly useful to users themselves, acting as an extension to their own hard drives.

The basic model is that 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, in the style of IP (Internet Protocol) routing. Depending on the key requested, routes will vary. The routing algorithms for storing and retrieving data described in the following sections are designed to adaptively adjust routes over time to provide efficient performance while using only local, rather than global, knowledge. This is necessary since nodes only have knowledge of their immediate upstream and downstream neighbors in the proxy chain, to maintain privacy.

Each request is given a hops-to-live limit, analogous to IP's time-to-live, which is decremented at each node to prevent infinite chains. Each request is also assigned a pseudo-unique random identifier, so that nodes can prevent loops by rejecting requests they have seen before. When this happens, the immediately-preceding node simply chooses a different node to forward to. This process continues until the request is either satisfied or exceeds its hops-to-live limit. Then the success or failure result is passed back up the chain to the sending node.

No node is privileged over any other node, so no hierarchy or central point of failure exists. Joining the network is simply a matter of first discovering the address of one or more existing nodes through out-of-band means, then starting to send messages.

>
>

Freenet è implementato come una rete adaptive peer-to-peer di nodi che si interrogano l'un l'altro per conservare e recuperare files di dati, che hanno un nome dato da chiavi location-independent. Ogni nodo mantiene il suo datastore locale che è reso disponibile alla rete in lettura e scrittura, come una tabella di routing dinamica che contiene indirizzi di altri nodi e le chiavi che si pensa che loro conservino. È sottointeso che una gran parte degli utenti del sistema faranno girare dei nodi, sia per dare garanzie di sicurezza contro l'uso involontario di un nodo esterno ostile, sia per incrementare la capacità di immagazzinamento dell'interno network.

Added:
>
>

Il sistema può essere considerato come un filesystem cooperativo distribuito che incorpora indipendenza di locazione e una lazy replication transparente. Semplicemente come i sistemi come distributed.net[15] che à la possibilità a utenti ordinari di condividere i cicli di CPU non utilizzati sulle loro macchine, Freenet dà ai suoi utenti la possibilità di condividere lo spazio sul disco che non usano. Comunque, mentre distributed.net usa questi cicli di CPU per i propri scopi, Freenet è direttamente utile agli utenti stessi, comportandosi come un'estensione dei loro dischi rigidi.

Il modello di base è che le richieste di chiavi sono passate da nodo a nodo attraverso una catena di richieste proxy nella quale ogni nodo fa una decisione locale su dove mandare dopo la richiesta, nello stile del routing IP (Internet Protocol). A seconda della chiave richiesta, i percorsi cambieranno. Gli algoritmi di routing per conservare e richiamare dati descritti nelle seguenti sezioni sono progettati per aggiustare adattivamente i percorsi nel tempo per dare performance efficienti mentre si usa una conoscenza solo locale, piuttosto che globale. Questo è necessario poichè i nodi conoscono solo gli upstream e downstream delle immediate vicinanze nella catena dei proxy, per mantenere la privacy.

A ogni richiesta viene dato un limite di hops-to-live, analogo al time-to-live dell'IP, che viene diminuto ad ogni nodo per evitare le catene infinite. A ogni richiesta viene anche assegnato un identificatore casuale pseudo-unico, così che i nodi possano prevenire i loop rifiutando le richieste che hanno già visto. Quando questo accade, il nodo immediatamente precedente semplicemente sceglie un altro nodo a cui passare la richiesta. Questo processo continua fino a che la richiesta viene soddisfatta o supera il suo limite di hops-to-live. Quindi il risultato di successo o di fallimento viene ripassato indietro lungo la catena fino al nodo inviante.

Nessun nodo è privilegiato rispetto a nessun altro, quindi non esiste gerarchia o un punto centrale di errore. Unirsi alla rete è semplicemente una questione di trovare per prima cosa l'indirizzo di uno o più nodi esistenti attraverso mezzi di fuori banda, e poi iniziare a mandare messaggi.

Changed:
<
<

La conservazione da parte dei nodi ` trattata come una Cache LRU (Least Recently Used, ovvero usato meno di recente ndt) [29] nella quale i singoli dati sono mantenuti ordinati in ordine decrescente per data della più recente richiesta (o data di inserimento, se una voce non è mai stata richiesta).

>
>

La conservazione da parte dei nodi è trattata come una Cache LRU (Least Recently Used, ovvero usato meno di recente ndt) [29] nella quale i singoli dati sono mantenuti ordinati in ordine decrescente per data della più recente richiesta (o data di inserimento, se una voce non è mai stata richiesta).

Changed:
<
<

Una transazione di Freenet inizia con un messaggio di Request.Handshake da un nodo a un altro, che specifica l'indirizzo di ritorno desiderato del nodo inviante.[*] (L'indirizzo di ritorno del mittente può essere impossibile da determinare automaticamente per il transport layer, o il mittente puo` desiderare di ricevere risposte a un indirizzo diverso da quello usato per mandare il messaggio.) Se un nodo remoto è attivo e risponde alle richieste, risponderà con una Reply.Handshake che specifica il numero di versione del protocollo che esso riesce a capire. Le handshakes vengono mantenute in memoria per qualche ora, e nelle transazioni seguenti tra gli stessi nodi durante questo tempo si potrà saltare questo passaggio.

>
>

Una transazione di Freenet inizia con un messaggio di Request.Handshake da un nodo a un altro, che specifica l'indirizzo di ritorno desiderato del nodo inviante.[*] (L'indirizzo di ritorno del mittente può essere impossibile da determinare automaticamente per il transport layer, o il mittente puoò desiderare di ricevere risposte a un indirizzo diverso da quello usato per mandare il messaggio.) Se un nodo remoto è attivo e risponde alle richieste, risponderà con una Reply.Handshake che specifica il numero di versione del protocollo che esso riesce a capire. Le handshakes vengono mantenute in memoria per qualche ora, e nelle transazioni seguenti tra gli stessi nodi durante questo tempo si potrà saltare questo passaggio.

Changed:
<
<

questo caso, Request.Continue è un risultato di fallimento che significa che non è stato possibile contattare tanti nodi quanti sono stati richiesti. Questi messaggi verranno passati come nel caso della richiesta. Entrambi i messaggi terminano la transazione e lasciano ogni risorsa che occupavano. Comunque, se l'inserzione scade senza incontrare una collisione, il nodo remoto risponderà con un Reply.Insert, indicando che l'inserzione può andare avanti. Il nodo inviante passer` la Reply.Insert e aspetterà che i suoi predecessori inviino un Send.Insert che contenga i dati. Quando riceve i dati, lo conserverà in locale e inoltrer` il flusso Send.Insert, concludendo la transazione.

>
>

questo caso, Request.Continue è un risultato di fallimento che significa che non è stato possibile contattare tanti nodi quanti sono stati richiesti. Questi messaggi verranno passati come nel caso della richiesta. Entrambi i messaggi terminano la transazione e lasciano ogni risorsa che occupavano. Comunque, se l'inserzione scade senza incontrare una collisione, il nodo remoto risponderà con un Reply.Insert, indicando che l'inserzione può andare avanti. Il nodo inviante passerà la Reply.Insert e aspetterà che i suoi predecessori inviino un Send.Insert che contenga i dati. Quando riceve i dati, lo conserverà in locale e inoltrerà il flusso Send.Insert, concludendo la transazione.


 <<O>>  Difference Topic ICSI (r1.2 - 22 Jan 2002 - MarcoCalamari)
Changed:
<
<

Si descrive qui Freenet, un'applicazione adattiva peer-to-peer in rete che

>
>

Viene descritta Freenet, un'applicazione adattiva peer-to-peer in rete che

Changed:
<
<

Non vengono utilizzati né la ricerca broadcast né un indice centralizzato delle

>
>

Non vengono utilizzati né la ricerca broadcast né un indice centralizzato delle

Changed:
<
<

E' impossibile scoprire la vera origine o destinazione di un file in transito nella rete,

>
>

È impossibile scoprire la vera origine o destinazione di un file in transito nella rete,

Changed:
<
<

  • Architecture
  • >
    >

  • Architettura
  • Changed:
    <
    <

  • Keys and searching
  • Retrieving data
  • Storing data
  • Managing data
  • Adding nodes
  • >
    >

  • Chiavi e ricerca
  • Recuperare dati
  • Memorizzare dati
  • Gestire dati
  • Aggiungere nodi
  • Changed:
    <
    <

  • Protocol details
  • Performance analysis
  • >
    >

  • Dettagli del protocollo
  • Analisi delle prestazioni
  • Changed:
    <
    <

  • Network convergence
  • Scalability
  • >
    >

  • Convergenza della rete
  • Scalabilità
  • Changed:
    <
    <

  • Small-world model
  • >
    >

  • Modello Small-world
  • Changed:
    <
    <

  • Security
  • Conclusions
  • Acknowledgements
  • Bibliography
  • >
    >

  • Sicurezza
  • Conclusioni
  • Ringraziamenti
  • Bibliografia
  • Changed:
    <
    <

    o che, semplicemente, potrebbero rivelarsi sovraccarichi in caso d'interessamento

    >
    >

    o che, semplicemente, potrebbero rivelarsi sovraccarichi in caso di carico

    Changed:
    <
    <

    di disponibilità. Freenet opera come file system distribuito e indipendente dalla collocazione,

    >
    >

    di disponibilità. Freenet opera come file system distribuito ed indipendente dalla collocazione,

    Changed:
    <
    <

  • Anonimato al tempo stesso per i produttori e per i fruitori delle informazioni
  • >
    >

  • Anonimato sia per i produttori chee per i fruitori delle informazioni
  • Changed:
    <
    <

  • Efficacia nella memorizzazione dinamica e instradamento delle informazioni
  • >
    >

  • Efficacia nella memorizzazione dinamica e nell'instradamento delle informazioni
  • Changed:
    <
    <

    Il sistema è progettato per rispondere in forma adattiva a schemi d'uso, spostando, riproducendo e cancellando i file con modalità trasparenti,

    >
    >

    Il sistema è progettato per rispondere in forma adattiva all'utilizzo, spostando, duplicando e cancellando i file in maniera trasparente

    Changed:
    <
    <

    a ricerche broadcast o ad indici centralizzati delle collocazioni dei dati.

    >
    >

    a ricerche broadcast o ad indici centralizzati delle posizioni dei dati.

    Changed:
    <
    <

    si auspica di riunire un numero sufficiente di nodi aventi capacità di memorizzazione

    >
    >

    si auspica di riunire un numero di nodi aventi capacità di memorizzazione

    Changed:
    <
    <

    Freenet è attualmente in sviluppo come progetto di software gratuito su Sourceforge, e una versione preliminare si può scaricare dal sito http://www.freenetproject.org/. Il nucleo del sistema è il lavoro iniziale svolto dal primo autore

    >
    >

    Freenet è attualmente in sviluppo come progetto di software libero su Sourceforge, ed una versione preliminare si può scaricare dal sito http://www.freenetproject.org/. L'origine del sistema è il lavoro iniziale svolto dal primo autore

    Changed:
    <
    <

    In quest'area si possono identificare diverse branchie di attività correlate a Freenet.

    >
    >

    In quest'area si possono identificare diversi settori di attività correlati a Freenet.

    Changed:
    <
    <

    implementato i canali punto punto anonimi basati sullo schema mix-net di Chaum[8]

    >
    >

    implementato i canali punto-punto anonimi basati sullo schema mix-net di Chaum[8]

    Changed:
    <
    <

    meglio visti come complemento a Freenet dal momento che non supportano l'accesso a file e l'archiviazione.

    >
    >

    meglio visti come complemento a Freenet, dal momento che non supportano l'accesso a file e l'archiviazione.

    Changed:
    <
    <

    L'anonimato per gli utenti dell'informazione nel contesto web è fornito da

    >
    >

    L'anonimato per gli utilizzatori dell'informazione nel web è fornito da

    Changed:
    <
    <

    gli utenti dal logging del servizio stesso. Le tecniche

    >
    >

    gli utilizzatori dal logging del servizio stesso. Le tecniche

    Changed:
    <
    <

    agli utenti dell'informazione, ma solo per quel che concerne il nascondere quale porzione

    >
    >

    agli utilizzatori dell'informazione, ma solo per quel che concerne il nascondere quale porzione

    Changed:
    <
    <

    stesso. TAZ[18] estende questa idea utilizzando catene di URL

    >
    >

    stesso. TAZ[18] estende quest'idea utilizzando catene di URL

    Changed:
    <
    <

    Entrambi si affidano a un unico server come sorgente ultima delle informazioni. Publius[30] aumenta la disponibilità distribuendo files come porzioni ridondanti tra n webservers, dei quali solo k sono necessari

    >
    >

    Entrambi si affidano ad un unico server come sorgente ultima delle informazioni. Publius[30] aumenta la disponibilità distribuendo file come porzioni ridondanti tra n webserver, dei quali solo k sono necessari

    Changed:
    <
    <

    distributed.net[15] ha dimostrato il concetto di associazione

    >
    >

    Distributed.net[15] ha dimostrato il concetto di associazione

    Changed:
    <
    <

    ``key-squatting''--inserting junk files under popular descriptions.

    >
    >

    "key-squatting"--inserting junk files under popular descriptions.

    Changed:
    <
    <

    ``similar'' key (determined by lexicographic distance) will be

    >
    >

    "similar" key (determined by lexicographic distance) will be

    Changed:
    <
    <

    is unable to contact any other nodes and returns a backtracking ``request failed'' message to b. Node b then tries its second choice,

    >
    >

    is unable to contact any other nodes and returns a backtracking "request failed" message to b. Node b then tries its second choice,

    Changed:
    <
    <

    similar to that key. It is therefore likely to gain more ``experience''

    >
    >

    similar to that key. It is therefore likely to gain more "experience"

    Changed:
    <
    <

    if the London node fails or is shut down. (Note that ``along the way''

    >
    >

    if the London node fails or is shut down. (Note that "along the way"

    Changed:
    <
    <

    detected, an ``all clear'' result will be propagated back to the

    >
    >

    detected, an "all clear" result will be propagated back to the

    Changed:
    <
    <

    Tutti i sistemi di conservazione delle informazioni devono tenere in considerazione il problema della capacità finita di conservare informazioni. I singoli gestori del nodo di Freenet possono configurare la grandezza dello spazio da dedicare ai loro magazzini di informazioni. La conservazione dei nodi ` trattata come una Cache LRU (Least Recently Used, ovvero usato meno di recente ndt) [29] nella quale i singoli dati sono mantenuti ordinati in ordine decrescente per data della più recente richiesta (o data di inserimento, se una voce non è mai stata richiesta). Quando arriva un nuovo file (o grazie a un nuovo inserimento o per una richiesta andata a buon fine) che potrebbe far aumentare la dimensione del magazzino di informazioni oltre la grandezza stabilita, i file usati meno di recente sono espulsi in ordine fino a che si crea lo spazio. Il risultante impatto sulla disponibilità è mitigato dal fatto che le voci della tabella di routing create quando i file espulsi sono arrivati per la prima volta rimarranno per un certo tempo, permettendo potenzialmente al nodo di procurarsi successivamente altre copie dalle fonti di dati originali. (Le voci della tabella di routing, infine, vengono anche cancellate in maniera simile quando la tabella si riempie, anche se saranno conservate più a lungo se sono più piccole.)

    >
    >

    Tutti i sistemi di conservazione delle informazioni devono tenere in considerazione il problema della capacità finita di conservare informazioni. I singoli gestori del nodo di Freenet possono configurare la grandezza dello spazio da dedicare alla memorizzaione dei dati (datastore). La conservazione da parte dei nodi ` trattata come una Cache LRU (Least Recently Used, ovvero usato meno di recente ndt) [29] nella quale i singoli dati sono mantenuti ordinati in ordine decrescente per data della più recente richiesta (o data di inserimento, se una voce non è mai stata richiesta). Quando arriva un nuovo file (o grazie a un nuovo inserimento o per una richiesta andata a buon fine) che potrebbe far aumentare la dimensione del gli utilizzatori oltre la grandezza stabilita, i file usati meno di recente sono espulsi in ordine fino a che si crea lo spazio. Il risultante impatto sulla disponibilità è mitigato dal fatto che le voci della tabella di routing create quando i file espulsi sono arrivati per la prima volta rimarranno per un certo tempo, permettendo potenzialmente al nodo di procurarsi successivamente altre copie dalle fonti di dati originali. (Le voci della tabella di routing, infine, vengono anche cancellate in maniera simile quando la tabella si riempie, anche se saranno conservate più a lungo se sono più piccole.)

    Changed:
    <
    <

    A voler essere precisi, il magazzino di informazioni non è una cache, poichè l'insieme dei magazzini di informazioni sono tutte le informazioni che sono lì. Cioè, non c'è una copia ``permanente'' che viene replicata in una cache. Una volta che tutti i nodi hanno deciso, parlando collettivamente, di abbandondare un determinato file, esso non sarà più disponibile per la rete. Riguardo a ciò, Freenet è diversa dai sistemi come Eternity e Free Haven che cercano di dare garanzie sui tempi di vita dei file.

    >
    >

    A voler essere precisi, il datastore non è una cache, poiché l'insieme dei datastore sono tutte le informazioni che sono lì. Cioè, non c'è una copia "permanente" che viene replicata in una cache. Una volta che tutti i nodi hanno deciso, parlando collettivamente, di eliminare un determinato file, esso non sarà più disponibile per la rete. Riguardo a ciò, Freenet è diversa dai sistemi come Eternity e Free Haven che cercano di dare garanzie sui tempi di vita dei file.

    Changed:
    <
    <

    Il meccanismo della scadenza ha un aspetto svantaggioso, comunque, poichè permette che i documenti vecchi svaniscano naturalmente dopo esser stati rimpiazzati da documenti più nuovi. Se un documento vecchio è ancora usato e considerato prezioso per ragioni storiche, resterà in vita fino a quando continuerà ad essere richiesto.

    >
    >

    Il meccanismo della scadenza ha un aspetto svantaggioso, comunque, poiché permette che i documenti vecchi svaniscano naturalmente dopo esser stati rimpiazzati da documenti più nuovi. Se un documento vecchio è ancora usato e considerato prezioso per ragioni storiche, resterà in vita fino a quando continuerà ad essere richiesto.

    Changed:
    <
    <

    Per ragioni politiche o legali, può essere desiderabile per gli operatori dei nodi non conoscere esplicitamente i contenuti dei loro magazzini di informazioni. E' per questo che tutti i file conservati sono criptati. Le procedure di crittazione usate non mirano a proteggere il file--questo sarebbe impossibile siccome chi fa una richiesta (potenzialmente chiunque) deve essere capace di decrittare il file una volta ricevuto. Piuttosto, la finalità è che il gestore di un nodo possa credibilmente negare ogni conoscenza del contenuto del suo magazzino di dati, poichè tutto ciò che sa a priori è la file key, non la encryption key. Le encryption keys per i dati keyword-signed e signed-subspace possono essere ottenute solo con un procedimento di reverse su un hash, e le encryption keys per i dati content-hash non sono affatto correlate. Con una certa difficoltà, naturalmente, un attacco basato sul dizionario svelerà quali keys sono presenti--poichè esso lo deve fare per le richieste per poter funzionare-- ma la fatica che un tale tentativo richiederebbe è intesa a fornire una misura di protezione per i gestori del nodo.

    >
    >

    Per ragioni politiche o legali, può essere desiderabile per gli operatori dei nodi non conoscere esplicitamente i contenuti dei loro datastore. È per questo che tutti i file conservati sono criptati. Le procedure di crittazione usate non mirano a proteggere il file; questo sarebbe impossibile poiché chi fa una richiesta (potenzialmente chiunque) deve essere capace di decrittare il file una volta ricevuto. Piuttosto, la finalità è che il gestore di un nodo possa credibilmente negare ogni conoscenza del contenuto del suo magazzino di dati, poiché tutto ciò che sa a priori è la file key, non la encryption key. Le encryption keys per i dati keyword-signed e signed-subspace possono essere ottenute solo con un procedimento di reverse su un hash, e le encryption keys per i dati content-hash non sono affatto correlate. Con una certa difficoltà, naturalmente, un attacco basato sul dizionario svelerà quali chiavi sono presenti--poiché esso lo deve fare per le richieste per poter funzionare-- ma la fatica che un tale tentativo richiederebbe è intesa a fornire una misura di protezione per i gestori del nodo.

    Changed:
    <
    <

    Ogni messaggio include un transaction ID cosicchè i nodi possono tracciare lo stato di inserimenti e richieste. Questo design è pensato per permettere flessibilità nella scelta del meccanismo di trasporto per i messaggi, se sia TCP, UDP, o altre tecnologie come packet radio.

    >
    >

    Ogni messaggio include un transaction ID cosicché i nodi possono tracciare lo stato di inserimenti e richieste. Questo design è pensato per permettere flessibilità nella scelta del meccanismo di trasporto per i messaggi, se sia TCP, UDP, o altre tecnologie come packet radio.

    Changed:
    <
    <

    Usando il limite di hops-to-live scelto, il nodo inviante fa partire un timer per la quantità di tempo prevista per contattare quei nodi, dopodichè supporrà un fallimento. Mentre la richiesta avviene, il nodo remoto può periodicamente mandare indietro messaggi Reply.Restart che indicano che i messaggi si sono bloccati aspettando timeouts della rete, cosicchè il nodo inviante sa di dover estendere il suo timer.

    >
    >

    Usando il limite di hops-to-live scelto, il nodo inviante fa partire un timer per la quantità di tempo prevista per contattare quei nodi, dopodiché supporrà un fallimento. Mentre la richiesta avviene, il nodo remoto può periodicamente mandare indietro messaggi Reply.Restart che indicano che i messaggi si sono bloccati aspettando timeouts della rete, cosicché il nodo inviante sa di dover estendere il suo timer.

    Changed:
    <
    <

    Se la richiesta è portata a termine con successo, il nodo remoto risponderà con un messaggio Send.Data che contiene i dati richiesti e l'indirizzo del nodo che lo ha fornito (è possibile che esso sia falso). Se la richiesta non è portata a termine con successo e le sue hops-to-live sono state usate completamente cercando di soddisfarla, il nodo remoto risponderà con un NotFound?. Il nodo inviante allora decrementerà le hops-to-live del Send.Data (o del NotFound?) e lo passerà, a meno che esso sia il vero originatore della richiesta. Entrambi questi messaggi termino la transazione e lasciano ogni risorsa che occupavano. Comunque, se ci sono ancora hops-to-live rimanenti, di solito perchè la richiesta è andata verso un vicolo cieco dove non c'è nessun sentiero che non genera un loop, il nodo remoto risponderà con una Request.Continue dando il numero di hops-to-live rimanenti. Il nodo inviante allora tenterà di contattare il prossimo nodo dalla sua tabella di routing. Esso manderà anche un messaggio Reply.Restart.

    >
    >

    Se la richiesta è portata a termine con successo, il nodo remoto risponderà con un messaggio Send.Data che contiene i dati richiesti e l'indirizzo del nodo che lo ha fornito (è possibile che esso sia falso). Se la richiesta non è portata a termine con successo e le sue hops-to-live sono state usate completamente cercando di soddisfarla, il nodo remoto risponderà con un NotFound?. Il nodo inviante allora decrementerà le hops-to-live del Send.Data (o del NotFound?) e lo passerà, a meno che esso sia il vero originatore della richiesta. Entrambi questi messaggi termino la transazione e lasciano ogni risorsa che occupavano. Comunque, se ci sono ancora hops-to-live rimanenti, di solito perché la richiesta è andata verso un vicolo cieco dove non c'è nessun sentiero che non genera un loop, il nodo remoto risponderà con una Request.Continue dando il numero di hops-to-live rimanenti. Il nodo inviante allora tenterà di contattare il prossimo nodo dalla sua tabella di routing. Esso manderà anche un messaggio Reply.Restart.

    Changed:
    <
    <

    Performance analysis

    >
    >

    Analisi delle prestazioni

    Changed:
    <
    <

    We performed simulations on a model of this system to give some indications about its performance. Here we summarize the most important results; for full details, see [21].

    >
    >

    Abbiamo eseguito delle simulazioni su un modello di questo sistema per ottenere alcune indicazioni sulle prestazioni ottenibili. Di seguito troverete i risultati più importanti; per avere dettagli completi, guarda [21].

    Changed:
    <
    <

    Network convergence

    >
    >

    Convergenza della rete

    Changed:
    <
    <

    To test the adaptivity of the network routing, we created a test network of 1000 nodes. Each node had a datastore size of 50 items and a routing table size of 250 addresses. The datastores were initialized to be empty, and the routing tables were initialized to connect the network in a regular ring-lattice topology in which each node had routing entries for its two nearest neighbors on either side. The keys associated with these routing entries were set to be hashes of the destination nodes' addresses. Using hashes has the useful property that the resulting keys are both random and consistent (that is, all references to a given node will use the same key).

    Inserts of random keys were sent to random nodes in the network, interspersed randomly with requests for randomly-chosen keys known to have been previously inserted, using a hops-to-live of 20 for both. Every 100 timesteps, a snapshot of the network was taken and its performance measured using a set of probe requests. Each probe consisted of 300 random requests for previously-inserted keys, using a hops-to-live of 500. We recorded the resulting distribution of request pathlengths, the number of hops actually taken before finding the data. If the request did not find the data, the pathlength was taken to be 500.

    >
    >

    Per testare l'adattività del routing di rete, abbiamo creato un network di 1000 nodi. Ogni nodo permette la memorizzazione di 50 "oggetti" all'interno del proprio datastore e, la gestione di 250 indirizzi nella propria tabella di routing. Ogni datastore è stato inizializzato con valori di default uguali a NULL, e le tabelle di routing secondo una configurazione che prende il nome di "lattice finito" in cui ogni nodo mantiene all'interno della propria tabella, gli indirizzi dei due nodi ad esso più "vicini". Le chiavi associate a questi indirizzi sono state create utilizzando l'hash degli stessi indirizzi remoti. Utilizzare una funzione di hash, ci consente di avere chiavi che sono casuali e consistenti (ogni riferimento ad un dato nodo utilizza la stessa chiave).

    Abbiamo inviato alcune richieste di inserimento di chiavi casuali ad altrettanti nodi scelti in modo accidentale, intercalate con alcune richieste (inviate sempre a nodi scelti a caso) per chiavi di cui sapevano già che era stato effettuato l'inserimento (la "profondità" del campo Hops-To-Live è stato impostato a 20 sia per i messaggi di inserimento che per quelli di richiesta). Ogni 100 "passaggi", l'intera rete è stata analizzata al fine di ricavare le prestazioni offerte dall'attuale struttura, utilizzando un set di richieste-prova. Ogni prova consisteva nella richiesta di 300 chiavi precedentemente inserite utilizzando un HTL di 500. Registrando i risultati cosí acquisiti, abbiamo potuto disegnare il grafico degli "hop" richiesti (lunghezza del percorso), prima di trovare i dati. Se la richiesta non andava a buon fine, la lunghezza del percorso la impostavamo a 500.

    Changed:
    <
    <

    >
    >

    <img WIDTH="582" HEIGHT="421" BORDER="0" SRC="/images/icsi-img3.gif">
    Changed:
    <
    <

    We can see that the initially high pathlengths decrease rapidly over time. In the beginning, few requests succeed at all, but as the network converges, the median request pathlength drops to just six.

    >
    >

    Possiamo vedere come la lunghezza dei percorsi iniziali, inizialmente elevata, decresca rapidamente nel tempo. All'inizio poche richieste di fatto vengono soddisfatte, ma mentre la rete converge, la media della lunghezza delle richieste, crolla a 6.

    Changed:
    <
    <

    Scalability

    >
    >

    Scalabilità

    Changed:
    <
    <

    Next, we examined the scalability of a growing network. Starting from a small network of 20 nodes initialized in the same manner as the previous section, we added new nodes over time and measured the change in the request pathlength.

    Inserts and requests were simulated randomly as before. Every five timesteps, a new node was created and added to the network by simulating a node announcement message with hops-to-live of 10 sent from it to a randomly-chosen existing node. The key assigned by this announcement was taken to be the hash of the new node's address. Note that this procedure does not necessarily imply a linear rate of network growth, but rather a linear relationship between the request rate and the growth rate. Since it seems likely that both rates will be proportional to network size (yielding an exponential growth rate in real, as opposed to simulated, time), we believe that this model is justifiable.

    >
    >

    Successivamente, abbiamo analizzato la scalabilità di una rete "nascente". Partendo da 20 nodi, inizializzati nel modo visto prima, abbiamo aggiunto nodi con il passare del tempo e misurato il cambiamento nelle "lunghezze del cammino" per raggiungere i dati.

    Inserimenti e Richieste sono stati simulati casualmente come visto prima. Ogni cinque passaggi, un nuovo nodo è stato creato e aggiunto alla rete simulando un "node announcement" con un HTL di 10 inviato ad un nodo già esistente. La chiave assegnata da questo "annuncio" è stata scelta come l'hash dell'indirizzo del nuovo nodo. Notate che questa procedura non implica necessariamente una tasso lineare nella crescita della rete, ma piuttosto una relazione lineare tra il tasso di richieste e il tasso di crescita.

    Changed:
    <
    <

    We can see that the pathlength scales approximately logarithmically, with a change of slope near 40,000 nodes. We posit that the slope change is a result of routing tables becoming filled and could be improved by adding a small number of nodes with larger routing tables. Section 5.4 discusses this issue in more depth. Where our routing tables were limited to 250 entries by the memory requirements of the simulation, real Freenet nodes should easily be able to hold thousands of entries. Nonetheless, even this limited network appears capable of scaling to one million nodes with a median pathlength of just 30. Note also that the network was grown continuously, without any steady-state convergence period.

    >
    >

    Possiamo notare come i "passi" necessari a raggiungere i dati tendono a crescere, in numero, secondo una funzione logaritmica, con un repentino cambio intorno ai 40.000 nodi. Abbiamo supposto che questo cambiamento (crollo) improvviso sia dovuto al completo riempimento delle tabelle di routing e puó essere facilmente eliminato inserendo alcuni nodi con tabelle decisamente piú "ampie". La sezione 5.4 discute queste questioni piú in dettaglio. Mentre le tabelle di routing da noi utilizzate per la simulazione sono limitate a 250 record, i nodi Freenet reali dovrebbero facilmente contenere migliaia di record. Non di meno val la pena far notare, che anche con una rete così limitata, riusciamo a scalare ad un milione di nodi con un percorso medio di 30 salti.

    Changed:
    <
    <

    Finally, we considered the fault-tolerance of the network. Starting with a network grown to 1000 nodes by the previous method, we progressively removed randomly-chosen nodes from the network to simulate node failures. Figure 4 shows the resulting evolution of the request pathlength, averaged over ten trials.

    >
    >

    Per concludere, abbiamo considerato la fault-tolerance del network. Partendo dalla rete di 1000 nodi ottenuta dal metodo precedente, abbiamo progressivamente rimosso (a caso...) alcuni nodi al fine di simularne il guasto degli stessi. La figura 4 mostra il cambiamento dei pathlengh dopo una decina di prove.

    Changed:
    <
    <

    >
    >

    <img WIDTH="582" HEIGHT="421" BORDER="0" SRC="/images/icsi-img5.gif" ALT="\begin{figure}\centerline{ \psfig{figure=03freenet4.eps,width=12cm} } \end{figure}">
    Changed:
    <
    <

    The network is surprisingly robust against quite large failures. The median pathlength remains below 20 even when up to 30% of nodes fail.

    >
    >

    La rete è sorprendentemente robusta anche dopo numerosi nodi "guasti". Il pathlenght medio rimane sotto 20 anche con il 30% di nodi falliti.

    Changed:
    <
    <

    The scalability and fault-tolerance characteristics of Freenet can be explained in terms of a small-world network model[<a

    >
    >

    La scalabilità e le caratteristiche fault-tolerance di Freenet possono essere spiegate in termini di un modello di rete small-world [<a

    Changed:
    <
    <

    HREF="#Albert">3]. In a small-world network, the majority of nodes have only relatively few, local, connections to other nodes, while a small number of nodes have large, wide-ranging sets of connections. Small-world networks permit efficient short paths between arbitrary points because of the shortcuts provided by the well-connected nodes, as evidenced by examination of Milgram's letter-passing experiment[<a HREF="#Milgram">23] and the Erdös number game cited by Watts and Strogatz[<a

    >
    >

    HREF="#Albert">3]. In una rete "small-world", la maggioranza dei nodi presenti hanno poche connessioni locali con gli altri nodi, mentre un esiguo numero di nodi possiede un numero elevato e largamente distribuito di connessioni. Una rete "Small-world" permette di avere "tracciati corti" tra punti arbitrari della rete grazie alle connessioni locali della maggioranza dei nodi (come si diceva sopra), come evidenziato dall'esperimento di Milgram [<a HREF="#Milgram">23] e il "gioco dei numeri di Erdös" spiegato da Watts e Strogatz[<a

    Changed:
    <
    <

    Is Freenet a small world? A key factor in the identification of a small-world network is the existence of a scale-free power-law distribution of links within the network, as the tail of such distributions provides the highly-connected nodes needed to create short paths. Figure 5 shows the average distribution of links (i.e. routing table entries) in the 1000-node Freenet networks used in the previous section.

    >
    >

    Si può affermare che Freenet è una rete "small-world" ? Un fattore chiave per l'identificazione di una rete "small-world" è l'esistenza di una "distribuzione esponenziale" del numero dei link tra i nodi della rete che induce l'esistenza di nodi "altamente" connessi a forzare brevi percorsi tra di essi. La figura 5 mostra la distribuzione media dei link in una rete Freenet di 1000 nodi utilizzata nella sessione precedente.

    Changed:
    <
    <

    >
    >

    <img WIDTH="582" HEIGHT="421" BORDER="0" SRC="/images/icsi-img6.gif" ALT="\begin{figure}\centerline{ \psfig{figure=03freenet5.eps,width=12cm} } \end{figure}">
    Changed:
    <
    <

    We see that the distribution closely approximates a power law, except for the anomalous point representing nodes with filled 250-entry routing tables. When we used differently-sized routing tables, this cutoff point moved but the power-law character of the distribution remained the same.

    In addition to providing short paths, the power-law distribution also gives small-world networks a high degree of fault-tolerance. Random failures are most likely to knock out nodes from the majority that possess only a small number of connections. The loss of poorly-connected nodes will not greatly affect routing in the network. It is only when the number of random failures becomes high enough to knock out a significant number of well-connected nodes that routing performance will be noticeably affected.

    >
    >

    Possiamo vedere come la distribuzione si avvicini ad un andamento esponenziale, eccetto per un punto "anomalo" dovuto al riempimento delle tabelle di routing. Nel momento in cui utilizziamo tabelle di routing di differente capacità, questo punto "critico" si sposta rimanendo invariata il carattere esponenziale della distribuzione.

    Oltre a ridurre il "cammino" minimo per raggiungere i dati, la distribuzione esponenziale da ad una rete "small-world" un alto grado di fault-tolerance. I fallimenti casuali di fatto eliminano dalla rete quei nodi che non posseggono un piccolo numero di connessioni. La perdita di nodi "poco connessi", non incidono piú di tanto il processo di routing all'interno della rete. Solo quando il fallimento (guasto n.d.t) di molti nodi comincia a crescere (eliminando dalla rete un significativo numero di nodi "ben connessi"), le performance subiscono un degrado importante.

    Changed:
    <
    <

    L'obiettivo primario della sicurezza di Freenet &egrave proteggere l'anonimato di coloro che richiedono o inseriscono file. Inoltre &egrave importante proteggere l'identit&agrave di coloro che fisicamente memorizzano le informazioni. Anche se chiunque pu&ograve banalmente fare in modo che un nodo memorizzi un dato file, richiedendolo attraverso quel nodo, ci&ograve che &egrave importante &egrave che quel file resti memorizzato anche presso altri

    >
    >

    L'obiettivo primario della sicurezza di Freenet è proteggere l'anonimato di coloro che richiedono o inseriscono file. Inoltre è importante proteggere l'identità di coloro che fisicamente memorizzano le informazioni. Anche se chiunque può banalmente fare in modo che un nodo memorizzi un dato file, richiedendolo attraverso quel nodo, ciò che è importante è che quel file resti memorizzato anche presso altri

    Changed:
    <
    <

    propriet&agrave della comunicazione anonima su tre assi. Il primo asse &egrave rappresenta il tipo di anonimato: anonimato del mittente

    >
    >

    proprietà della comunicazione anonima su tre assi. Il primo asse è rappresenta il tipo di anonimato: anonimato del mittente

    Changed:
    <
    <

    non pu&ograve identificare chi ha originato il messaggio o chi &egrave supposto riceverlo. Il secondo asse &egrave il nemico in questione:

    >
    >

    non può identificare chi ha originato il messaggio o chi è supposto riceverlo. Il secondo asse è il nemico in questione:

    Changed:
    <
    <

    Freenet). Il terzo asse &egrave il grado di anonimato, che varia da "riservatezza assoluta" (impossibilit&agrave di rilevare il fatto che

    >
    >

    Freenet). Il terzo asse è il grado di anonimato, che varia da "riservatezza assoluta" (impossibilità di rilevare il fatto che

    Changed:
    <
    <

    non ha maggior probabilit&agrave di essere identificato come tale

    >
    >

    non ha maggior probabilità di essere identificato come tale

    Changed:
    <
    <

    (il fatto che il vero mittente sia tale non &egrave pi&ugrave probabile

    >
    >

    (il fatto che il vero mittente sia tale non è più probabile

    Changed:
    <
    <

    "smascherato con le prove" (il nemico pu&ograve dimostrare ad altri chi &egrave il mittente).

    >
    >

    "smascherato con le prove" (il nemico può dimostrare ad altri chi è il mittente).

    Changed:
    <
    <

    Poich&eacute la comunicazione su Freenet non &egrave diretta a destinatari specifici, l'anonimato del ricevente pu&ograve essere

    >
    >

    Poich&eacute la comunicazione su Freenet non è diretta a destinatari specifici, l'anonimato del ricevente può essere

    Changed:
    <
    <

    della chiave, la riservatezza della chiave non pu&ograve essere ottenuta con lo schema Freenet di base (vedi per&ograve la discussione sul 'pre-routing' pi&ugrave sotto). L'uso di funzioni hash come chiavi permette di difendersi contro l'intercettazione casuale, ma &egrave

    >
    >

    della chiave, la riservatezza della chiave non può essere ottenuta con lo schema Freenet di base (vedi però la discussione sul 'pre-routing' più sotto). L'uso di funzioni hash come chiavi permette di difendersi contro l'intercettazione casuale, ma è

    Changed:
    <
    <

    Le propriet&agrave di anonimato di Freenet sulla base di questa tassonomia

    >
    >

    Le proprietà di anonimato di Freenet sulla base di questa tassonomia

    Changed:
    <
    <

    Propriet&agrave di anonimato in Freenet.

    >
    >

    Proprietà di anonimato in Freenet.

    Changed:
    <
    <

    Contro un insieme di nodi maligni, l'anonimato del mittente &egrave preservato oltre ogni sospetto poich&eacute un nodo sul percorso di richiesta non &egrave

    >
    >

    Contro un insieme di nodi maligni, l'anonimato del mittente è preservato oltre ogni sospetto poich&eacute un nodo sul percorso di richiesta non è

    Changed:
    <
    <

    probabilit&agrave che una richiesta che arriva al nodo a sia inoltrata o gestita direttamente e della probabilit&agrave che a scelga un particolare nodo b per inoltrare la richiesta. Tale analisi non &egrave comunque applicabile

    >
    >

    probabilità che una richiesta che arriva al nodo a sia inoltrata o gestita direttamente e della probabilità che a scelga un particolare nodo b per inoltrare la richiesta. Tale analisi non è comunque applicabile

    Changed:
    <
    <

    il dato richiesto nel datastore pi&ugrave che da fattori random. Se una richiesta viene

    >
    >

    il dato richiesto nel datastore più che da fattori random. Se una richiesta viene

    Changed:
    <
    <

    In ogni caso, il valore di "depth" pu&ograve fornire alcune indicazioni sulla distanza del nodo di origine, anche se &egrave nascosta dalla selezione casuale della "depth"

    >
    >

    In ogni caso, il valore di "depth" può fornire alcune indicazioni sulla distanza del nodo di origine, anche se è nascosta dalla selezione casuale della "depth"

    Changed:
    <
    <

    Non vi &egrave protezione dei messaggi contro l'intercettazione sul percorso tra l'utente e il primo nodo. Poich&eacute il primo nodo pu&ograve agire da

    >
    >

    Non vi è protezione dei messaggi contro l'intercettazione sul percorso tra l'utente e il primo nodo. Poich&eacute il primo nodo può agire da

    Changed:
    <
    <

    sono crittati contro l'intercettazione, ma &egrave comunque possibile effettuare un'analisi del traffico (ad esempio si pu&ograve osservare un messaggio

    >
    >

    sono crittati contro l'intercettazione, ma è comunque possibile effettuare un'analisi del traffico (ad esempio si può osservare un messaggio

    Changed:
    <
    <

    messaggio &egrave stato generato localmente).

    >
    >

    messaggio è stato generato localmente).

    Changed:
    <
    <

    La riservatezza delle chiavi ed una pi&ugrave forte protezione dell'anonimato del mittente possono essere ottenute introducendo un ``pre-routing'' dei

    >
    >

    La riservatezza delle chiavi ed una più forte protezione dell'anonimato del mittente possono essere ottenute introducendo un "pre-routing" dei

    Changed:
    <
    <

    determinano il percorso che il messaggio seguir&agrave (bypassando il normale

    >
    >

    determinano il percorso che il messaggio seguirà (bypassando il normale

    Changed:
    <
    <

    La protezione per la sorgente dei dati &egrave assicurata dalla riscrittura

    >
    >

    La protezione per la sorgente dei dati è assicurata dalla riscrittura

    Changed:
    <
    <

    corso della richiesta. Non &egrave possibile decidere se il nodo a valle

    >
    >

    corso della richiesta. Non è possibile decidere se il nodo a valle

    Changed:
    <
    <

    memorizzato il dato, poich&eacute continuano con probabilit&agrave finita

    >
    >

    memorizzato il dato, poich&eacute continuano con probabilità finita

    Changed:
    <
    <

    consistente numero di richieste di file correlati pu&ograve fornire tuttavia una base

    >
    >

    consistente numero di richieste di file correlati può fornire tuttavia una base

    Changed:
    <
    <

    catena di richiesta costituisce una grave minaccia, e non solo per l'integrit&agrave

    >
    >

    catena di richiesta costituisce una grave; minaccia, e non solo per l'integrità

    Changed:
    <
    <

    questo non &egrave attuabile poich&eacute dati non autentici possono essere

    >
    >

    questo non è attuabile poich&eacute dati non autentici possono essere

    Changed:
    <
    <

    Infine, si pu&ograve prevedere un certo numero di attacchi di tipo denial-of-service. La minaccia pi&ugrave grave &egrave che un utente cerchi di saturare la capacit&agrave di memorizzazione della rete con l'inserimento di grandi quantit&agrave di dati non significativi. Un'interessante possibilit&agrave di contrastare questi attacchi &egrave l'uso di schemi come l'Hash Cash [<a

    >
    >

    Infine, si può prevedere un certo numero di attacchi di tipo denial-of-service. La minaccia più grave è che un utente cerchi di saturare la capacità di memorizzazione della rete con l'inserimento di grandi quantità di dati non significativi. Un'interessante possibilità di contrastare questi attacchi è l'uso di schemi come l'Hash Cash [<a

    Changed:
    <
    <

    inserisce un dato debba effettuare un'elaborazione complessa come ``tassa'' per l'inserimento, in modo da rallentare l'attacco. Un'altra alternativa &egrave quella

    >
    >

    inserisce un dato debba effettuare un'elaborazione complessa come "tassa" per l'inserimento, in modo da rallentare l'attacco. Un'altra alternativa è quella

    Changed:
    <
    <

    per i file ``stabili'', che hanno cio&egrave gi&agrave ricevuto un certo numero di richieste. I nuovi inserimenti possono solo rimpiazzare altri file ``nuovi''. In questo modo, l'inserimento massiccio di dati non significativi pu&ograve solo paralizzare

    >
    >

    per i file "stabili", che hanno cioè già ricevuto un certo numero di richieste. I nuovi inserimenti possono solo rimpiazzare altri file "nuovi". In questo modo, l'inserimento massiccio di dati non significativi può solo paralizzare

    Changed:
    <
    <

    file importanti. Risulta infatti difficile ``legittimare'' artificialmente

    >
    >

    file importanti. Risulta infatti difficile "legittimare" artificialmente

    Changed:
    <
    <

    oltre. D'altra parte, non &egrave possibile interrogare direttamente i nodi a valle poich&egrave non se ne conosce l'identit&agrave. In ogni caso, l'adozione di questo schema pu&ograve compromettere la sopravvivenza di dati legittimi per un

    >
    >

    oltre. D'altra parte, non è possibile interrogare direttamente i nodi a valle poiché non se ne conosce l'identit&agrave. In ogni caso, l'adozione di questo schema può compromettere la sopravvivenza di dati legittimi per un

    Changed:
    <
    <

    Si pu&ograve tentare di rimpiazzare file esistenti inserendo versioni diverse di essi sotto le stesse chiavi. Questo tipo di attacco non &egrave possibile

    >
    >

    Si può tentare di rimpiazzare file esistenti inserendo versioni diverse di essi sotto le stesse chiavi. Questo tipo di attacco non è possibile

    Changed:
    <
    <

    una chiave keyword-signed, d'altra parte, pu&ograve portare alla coesistenza delle due versioni nella rete. Le modalit&agrave con cui i nodi trattano le collisioni

    >
    >

    una chiave keyword-signed, d'altra parte, può portare alla coesistenza delle due versioni nella rete. Le modalità con cui i nodi trattano le collisioni

    Changed:
    <
    <

    da rendere questi attacchi pi&ugrave difficili. Il successo di un attacco a rimpiazzo pu&ograve essere misurato con il rapporto tra il numero di versioni originali del file e il numero di versioni corrotte presenti nel sistema. In ogni caso, maggiore &egrave il

    >
    >

    da rendere questi attacchi più difficili. Il successo di un attacco a rimpiazzo può essere misurato con il rapporto tra il numero di versioni originali del file e il numero di versioni corrotte presenti nel sistema. In ogni caso, maggiore è il

    Changed:
    <
    <

    nell'inserimento), maggiore &egrave la probabilit&agrave che si realizzi una collisione,

    >
    >

    nell'inserimento), maggiore è la probabilità che si realizzi una collisione,

    Changed:
    <
    <

    anonima del sistema, &egrave impossibile decidere con esattezza quanti utenti vi siano

    >
    >

    anonima del sistema, è impossibile decidere con esattezza quanti utenti vi siano

    Changed:
    <
    <

    e visualizzazione che permetter&agrave di effettuare prove pi&ugrave rigorose sul protocollo e sul meccanismo di instradamento. &Egrave necessaria nna simulazione pi&ugrave &egrave

    >
    >

    e visualizzazione che permetterà di effettuare prove più rigorose sul protocollo e sul meccanismo di instradamento. È necessaria nna simulazione più è

    Changed:
    <
    <

    variazione della capacit&agrave e della larghezza di banda dei nodi, e di dimensioni maggiori

    >
    >

    variazione della capacità e della larghezza di banda dei nodi, e di dimensioni maggiori

    Changed:
    <
    <

    Questo materiale &egrave basato parzialmente su lavori patrocinati da una

    >
    >

    Questo materiale è basato parzialmente su lavori patrocinati da una

    Changed:
    <
    <

    S. Adler, ``The Slashdot effect: an analysis of three Internet publications,'' Linux Gazette issue 38, March 1999.

    >
    >

    S. Adler, "The Slashdot effect: an analysis of three Internet publications," Linux Gazette issue 38, March 1999.

    Changed:
    <
    <

    R. Albert, H. Jeong, and A. Barabási, ``Error and attack tolerance of complex networks,'' Nature 406,

    >
    >

    R. Albert, H. Jeong, and A. Barabási, "Error and attack tolerance of complex networks," Nature 406,

    Changed:
    <
    <

    R.J. Anderson, ``The Eternity service,'' in Proceedings of the 1st

    >
    >

    R.J. Anderson, "The Eternity service," in Proceedings of the 1st

    Changed:
    <
    <

    O. Berthold, H. Federrath, and S. Köpsell, ``Web MIXes: a system for anonymous and unobservable Internet access,'' in Proceedings

    >
    >

    O. Berthold, H. Federrath, and S. Köpsell, "Web MIXes: a system for anonymous and unobservable Internet access," in Proceedings

    Changed:
    <
    <

    D.L. Chaum, ``Untraceable electronic mail, return addresses, and digital pseudonyms,'' Communications of the ACM 24(2), 84-88 (1981).

    >
    >

    D.L. Chaum, "Untraceable electronic mail, return addresses, and digital pseudonyms," Communications of the ACM 24(2), 84-88 (1981).

    Changed:
    <
    <

    P. Yianilos, ``A prototype implementation of archival intermemory,''

    >
    >

    P. Yianilos, "A prototype implementation of archival intermemory,"

    Changed:
    <
    <

    B. Chor, O. Goldreich, E. Kushilevitz, and M. Sudan, ``Private information retrieval,'' Journal of the ACM 45(6), 965-982 (1998).

    >
    >

    B. Chor, O. Goldreich, E. Kushilevitz, and M. Sudan, "Private information retrieval," Journal of the ACM 45(6), 965-982 (1998).

    Changed:
    <
    <

    I. Clarke, ``A distributed decentralised information storage and retrieval system,'' unpublished report, Division of

    >
    >

    I. Clarke, "A distributed decentralised information storage and retrieval system," unpublished report, Division of

    Changed:
    <
    <

    L. Cottrell, ``Frequently asked questions about Mixmaster remailers,'' http://www.obscura.com/~loki/remailer/mixmaster-faq.html

    >
    >

    L. Cottrell, "Frequently asked questions about Mixmaster remailers," http://www.obscura.com/~loki/remailer/mixmaster-faq.html

    Changed:
    <
    <

    R. Dingledine, M.J. Freedman, and D. Molnar, ``The Free Haven project: distributed anonymous storage service,'' in Proceedings of the

    >
    >

    R. Dingledine, M.J. Freedman, and D. Molnar, "The Free Haven project: distributed anonymous storage service," in Proceedings of the

    Changed:
    <
    <

    D.J. Ellard, J.M. Megquier, and L. Park, ``The INDIA protocol,'' http://www.eecs.harvard.edu/~ellard/India-WWW/

    >
    >

    D.J. Ellard, J.M. Megquier, and L. Park, "The INDIA protocol," http://www.eecs.harvard.edu/~ellard/India-WWW/

    Changed:
    <
    <

    I. Goldberg and D. Wagner, ``TAZ servers and the rewebber network: enabling anonymous publishing on the world wide web,'' First

    >
    >

    I. Goldberg and D. Wagner, "TAZ servers and the rewebber network: enabling anonymous publishing on the world wide web," First

    Changed:
    <
    <

    D. Goldschlag, M. Reed, and P. Syverson, ``Onion routing for anonymous and private Internet connections,'' Communications of the ACM 42(2), 39-41 (1999).

    >
    >

    D. Goldschlag, M. Reed, and P. Syverson, "Onion routing for anonymous and private Internet connections," Communications of the ACM 42(2), 39-41 (1999).

    Changed:
    <
    <

    T. Hong, ``Performance,'' in Peer-to-Peer, ed. by A. Oram. O'Reilly:

    >
    >

    T. Hong, "Performance," in Peer-to-Peer, ed. by A. Oram. O'Reilly:

    Changed:
    <
    <

    B.A. Huberman and L.A. Adamic, ``Growth dynamics of the world-wide web,'' Nature 401, 131 (1999).

    >
    >

    B.A. Huberman and L.A. Adamic, "Growth dynamics of the world-wide web," Nature 401, 131 (1999).

    Changed:
    <
    <

    S. Milgram, ``The small world problem,'' Psychology Today 1(1),

    >
    >

    S. Milgram, "The small world problem," Psychology Today 1(1),

    Changed:
    <
    <

    M.K. Reiter and A.D. Rubin, ``Anonymous web transactions with Crowds,'' Communications of the ACM 42(2), 32-38 (1999).

    >
    >

    M.K. Reiter and A.D. Rubin, "Anonymous web transactions with Crowds," Communications of the ACM 42(2), 32-38 (1999).

    Changed:
    <
    <

    M. Richtel and S. Robinson, ``Several web sites are attacked on day after assault shut Yahoo,'' The New York Times, February 9, 2000.

    >
    >

    M. Richtel and S. Robinson, "Several web sites are attacked on day after assault shut Yahoo," The New York Times, February 9, 2000.

    Changed:
    <
    <

    J. Rosen, ``The eroded self,'' The New York Times, April 30, 2000.

    >
    >

    J. Rosen, "The eroded self," The New York Times, April 30, 2000.

    Changed:
    <
    <

    M. Waldman, A.D. Rubin, and L.F. Cranor, ``Publius: a robust, tamper-evident, censorship-resistant, web publishing system,'' in Proceedings of the Ninth USENIX Security Symposium, Denver, CO, USA

    >
    >

    M. Waldman, A.D. Rubin, and L.F. Cranor, "Publius: a robust, tamper-evident, censorship-resistant, web publishing system," in Proceedings of the Ninth USENIX Security Symposium, Denver, CO, USA

    Changed:
    <
    <

    D. Watts and S. Strogatz, ``Collective dynamics of `small-world' networks,''

    >
    >

    D. Watts and S. Strogatz, "Collective dynamics of `small-world' networks,"

    Changed:
    <
    <

    Il lavoro di Theodore W. Hong &egrave
    >
    >

    Il lavoro di Theodore W. Hong è
    Changed:
    <
    <

    Ricorda che il nodo a monte pu&ograve o meno essere il richiedente originale.
    >
    >

    Ricorda che il nodo a monte può o meno essere il richiedente originale.

     <<O>>  Difference Topic ICSI (r1.1 - 21 Jan 2002 - MarcoCalamari)
    Added:
    >
    >

    %META:TOPICINFO{author="MarcoCalamari" date="1011607020" format="1.0" version="1.1"}% %META:TOPICPARENT{name="Publicity"}%

    Freenet: Un sistema anonimo distribuito di memorizzazione e ricerca di informazioni

    Ian Clarke
    Uprizer, Inc.
    1007 Montana Ave., #323
    Santa Monica, CA 90403
    USA
    ian@octayne.com
    Oskar Sandberg
    Department of Numerical Analysis and Computer Science
    Royal Institute of Technology
    SE-100 44 Stockholm
    Sweden
    md98-osa@nada.kth.se
    Brandon Wiley
    College of Communication
    University of Texas at Austin
    Austin, TX 78712
    USA
    blanu@uts.cc.utexas.edu
    Theodore W. Hong[*]
    Department of Computing
    Imperial College of Science, Technology and Medicine
    180 Queen's Gate, London SW7 2BZ
    United Kingdom
    t.hong@doc.ic.ac.uk

    Testo approvato il 1° luglio 2000
    Rivisto il 18 dicembre 2000


    Sunto:

    Si descrive qui Freenet, un'applicazione adattiva peer-to-peer in rete che consente di pubblicare, riprodurre e ricercare dati salvaguardando l'anonimato degli autori e dei lettori. Freenet opera come una rete di nodi identici che, collettivamente, mettono in comune il loro spazio di memoria per memorizzare file di dati e cooperano tra di loro per inoltrare le richieste verso le più probabili collocazioni fisiche dei dati stessi. Non vengono utilizzati né la ricerca broadcast né un indice centralizzato delle collocazioni dei dati; il riferimento ai file avviene secondo una modalità indipendente dalle collocazioni, ed i file vengono riprodotti dinamicamente in località vicine ai richiedenti e cancellati dalle località dove non si riscontra interesse. E' impossibile scoprire la vera origine o destinazione di un file in transito nella rete, ed è difficile per un operatore di un nodo determinare o attribuirgli la responsabilità del contenuto concreto del suo nodo.




    Introduzione

    I sistemi computerizzati in rete stanno acquistando sempre maggiore importanza come mezzo preferito per memorizzare e scambiare informazioni. Tuttavia, i sistemi attuali offrono ai loro utenti scarsa privacy e, di norma, memorizzano ogni elemento dei dati soltanto in uno o pochi posti fissi, creando un punto debole centrale. Gli autori ed i lettori desiderano però salvaguardare la propria privacy riguardo a vari tipi d'informazioni delicate[28], ed è inopportuno che vi siano punti deboli centrali, sui quali potrebbe intervenire chi voglia danneggiare il sistema togliendogli dati[11,27] o che, semplicemente, potrebbero rivelarsi sovraccarichi in caso d'interessamento eccessivo[1]; sono quindi necessari sistemi che offrano maggiore sicurezza e affidabilità.

    Noi stiamo sviluppando Freenet, un sistema distribuito di memorizzazione e di ricerca d'informazioni, che intende soddisfare queste esigenze di privacy e di disponibilità. Freenet opera come file system distribuito e indipendente dalla collocazione, attraverso numerosi singoli computer, che consentono di immettere, memorizzare e ricercare i file anonimamente. Gli obiettivi principali di questo progetto sono cinque:

    • Anonimato al tempo stesso per i produttori e per i fruitori delle informazioni
    • Immunità per chi mantiene le informazioni
    • Resistenza a tentativi di terzi di negare l'accesso alle informazioni
    • Efficacia nella memorizzazione dinamica e instradamento delle informazioni
    • Decentramento di tutte le funzioni della rete

    Il sistema è progettato per rispondere in forma adattiva a schemi d'uso, spostando, riproducendo e cancellando i file con modalità trasparenti, secondo le necessità, per offrire un servizio efficiente senza dover ricorrere a ricerche broadcast o ad indici centralizzati delle collocazioni dei dati. Non si intende garantire la memorizzazione permanente dei file, anche se si auspica di riunire un numero sufficiente di nodi aventi capacità di memorizzazione sufficiente per poter conservare a tempo indeterminato la massima parte dei file. Inoltre, il sistema opera al livello delle applicazioni e, pur essendo indipendente dal trasporto, presume la presenza di uno strato di trasporto sicuro. Scopo del sistema è preservare l'anonimato non per l'utilizzo generale della rete ma soltanto per le operazioni con i file di Freenet.

    Freenet è attualmente in sviluppo come progetto di software gratuito su Sourceforge, e una versione preliminare si può scaricare dal sito http://www.freenetproject.org/. Il nucleo del sistema è il lavoro iniziale svolto dal primo autore presso l'Università di Edimburgo[12].

    Attività correlate

    In quest'area si possono identificare diverse branchie di attività correlate a Freenet. Il remailer Mixmaster[13] per le email, l'onion routing[19] e Freedom[32] per il traffico tcp/ip generico hanno implementato i canali punto punto anonimi basati sullo schema mix-net di Chaum[8] Tuttavia questi canali non sono in sè facilmente adattabili alla pubblicazione "uno a molti" e sono meglio visti come complemento a Freenet dal momento che non supportano l'accesso a file e l'archiviazione.

    L'anonimato per gli utenti dell'informazione nel contesto web è fornito da servizi di proxy da browser come Anonymizer[6], sebbene questi non forniscono protezione per chi offre l'informazione e non proteggono gli utenti dal logging del servizio stesso. Le tecniche di recupero di informazioni private[10] danno garanzie molto più valide agli utenti dell'informazione, ma solo per quel che concerne il nascondere quale porzione dell'informazione è stata recuperata e da quale specifico server. In molti casi, il fatto stesso di contattare un particolare server può rivelare ulteriori dati sull'informazione stessa recuperata, e questo sarebbe inutile solo se ogni server mantenesse tutte le informazioni (naturalmente questo ha poco peso). Il lavoro più vicino al nostro è il sistema Crowds di Reiter e Rubin[25], che usa un metodo simile di richieste proxy per gli utenti, sebbene Crowds in sè non memorizza informazioni e non protegge chi offre l'informazione. Berthold et al. propone Web MIXes[7], un sistema più forte che, per aumentare la sicurezza, utilizza il message padding (infarcimento dei messaggi), la riordinazione e i messaggi finti, ma ancora non protegge chi offre l'informazione.

    Il Rewebber[26] fornisce un grado di anonimato a chi offre informazioni web per mezzo di un servizio di URL criptate che è essenzialmente l'inverso del proxy da browser, ma con lo stesso limite di non fornire protezione contro la facoltà di "intervento" da parte del servizio stesso. TAZ[18] estende questa idea utilizzando catene di URL criptate nidificate che puntano a diversi server rewebber contattati in successione, tuttavia questo è vulnerabile all'analisi del traffico utilizzando il "replay". Entrambi si affidano a un unico server come sorgente ultima delle informazioni. Publius[30] aumenta la disponibilità distribuendo files come porzioni ridondanti tra n webservers, dei quali solo k sono necessari per ricostruire un file; Tuttavia, dal momento in cui l'identità degli stessi server non è anonima, un aggressore potrebbe rimuovere le informazioni forzando la chiusura di n-k+1 servers. La proposta The Eternity [5] mira ad archiviare informazioni permanentemente e in modo anonimo, sebbene manchi di specifiche su come localizzare efficentemente i files archiviati e risultando così più simile a un servizio di backup anonimo. Free Haven[14] è un interessante sistema di pubblicazione anonima che fa uso di una rete fidata e un meccanismo di scambio file per fornire una maggiore responsabilità dal lato server mantenendo l'anonimato.

    distributed.net[15] ha dimostrato il concetto di associazione in larga scala di risorse CPU tra i computer di molti utenti; Altri sistemi che fanno lo stesso, ma per lo spazio disco, sono Napster[24] e Gnutella[17]; il primo si affida a un server centrale per localizzare i files e il secondo impiega un'inefficiente ricerca broadcast. Nessuno dei due replica i files. Intermemory[9] e India[16] sono sistemi cooperanti di fileserver distribuito, pensati per l'archiviazione di dati a lungo termine secondo il concetto di Eternity, per cui i files sono divisi in porzioni ridondanti e distribuiti tra svariati partecipanti. Akamai[2] fornisce un servizio che replica i files nelle aree in cui si trovano gli utenti che ne usufruiscono, ma non è adeguato per chi volesse offrire il servizio a livello individuale (non come organizzazione). Nessuno di questi sistemi cerca di fornire anonimato.

    Architecture

    Freenet is implemented as an adaptive peer-to-peer network of nodes that query one another to store and retrieve data files, which are named by location-independent keys. Each node maintains its own local datastore which it makes available to the network for reading and writing, as well as a dynamic routing table containing addresses of other nodes and the keys that they are thought to hold. It is intended that most users of the system will run nodes, both to provide security guarantees against inadvertently using a hostile foreign node and to increase the storage capacity available to the network as a whole.

    The system can be regarded as a cooperative distributed filesystem incorporating location independence and transparent lazy replication. Just as systems such as distributed.net[15] enable ordinary users to share unused CPU cycles on their machines, Freenet enables users to share unused disk space. However, where distributed.net uses those CPU cycles for its own purposes, Freenet is directly useful to users themselves, acting as an extension to their own hard drives.

    The basic model is that 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, in the style of IP (Internet Protocol) routing. Depending on the key requested, routes will vary. The routing algorithms for storing and retrieving data described in the following sections are designed to adaptively adjust routes over time to provide efficient performance while using only local, rather than global, knowledge. This is necessary since nodes only have knowledge of their immediate upstream and downstream neighbors in the proxy chain, to maintain privacy.

    Each request is given a hops-to-live limit, analogous to IP's time-to-live, which is decremented at each node to prevent infinite chains. Each request is also assigned a pseudo-unique random identifier, so that nodes can prevent loops by rejecting requests they have seen before. When this happens, the immediately-preceding node simply chooses a different node to forward to. This process continues until the request is either satisfied or exceeds its hops-to-live limit. Then the success or failure result is passed back up the chain to the sending node.

    No node is privileged over any other node, so no hierarchy or central point of failure exists. Joining the network is simply a matter of first discovering the address of one or more existing nodes through out-of-band means, then starting to send messages.


    Keys and searching

    Files in Freenet are identified by binary file keys obtained by applying a hash function. Currently we use the 160-bit SHA-1[4] function as our hash. Three different types of file keys are used, which vary in purpose and in the specifics of how they are constructed.

    The simplest type of file key is the keyword-signed key (KSK), which is derived from a short descriptive text string chosen by the user when storing a file in the network. For example, a user inserting a treatise on warfare might assign it the description, text/philosophy/sun-tzu/art-of-war. This string is used as input to deterministically generate a public/private key pair. The public half is then hashed to yield the file key.

    The private half of the asymmetric key pair is used to sign the file, providing a minimal integrity check that a retrieved file matches its file key. Note however that an attacker can use a dictionary attack against this signature by compiling a list of descriptive strings. The file is also encrypted using the descriptive string itself as a key, for reasons to be explained in section 3.4.

    To allow others to retrieve the file, the user need only publish the descriptive string. This makes keyword-signed keys easy to remember and communicate to others. However, they form a flat global namespace, which is problematic. Nothing prevents two users from independently choosing the same descriptive string for different files, for example, or from engaging in ``key-squatting''--inserting junk files under popular descriptions.

    These problems are addressed by the signed-subspace key (SSK), which enables personal namespaces. A user creates a namespace by randomly generating a public/private key pair which will serve to identify her namespace. To insert a file, she chooses a short descriptive text string as before. The public namespace key and the descriptive string are hashed independently, XOR'ed together, and then hashed again to yield the file key.

    As with the keyword-signed key, the private half of the asymmetric key pair is used to sign the file. This signature, generated from a random key pair, is more secure than the signatures used for keyword-signed keys. The file is also encrypted by the descriptive string as before.

    To allow others to retrieve the file, the user publishes the descriptive string together with her subspace's public key. Storing data requires the private key, however, so only the owner of a subspace can add files to it.

    The owner now has the ability to manage her own namespace. For example, she could simulate a hierarchical structure by creating directory-like files containing hypertext pointers to other files. A directory under the key text/philosophy could contain a list of keys such as text/philosophy/sun-tzu/art-of-war, text/philosophy/confucius/analects, and text/philosophy/nozick/anarchy-state-utopia, using appropriate syntax interpretable by a client. Directories can also recursively point to other directories.

    The third type of key is the content-hash key (CHK), which is useful for implementing updating and splitting. A content-hash key is simply derived by directly hashing the contents of the corresponding file. This gives every file a pseudo-unique file key. Files are also encrypted by a randomly-generated encryption key. To allow others to retrieve the file, the user publishes the content-hash key itself together with the decryption key. Note that the decryption key is never stored with the file but is only published with the file key, for reasons to be explained in section 3.4.

    Content-hash keys are most useful in conjunction with signed-subspace keys using an indirection mechanism. To store an updatable file, a user first inserts it under its content-hash key. She then inserts an indirect file under a signed-subspace key whose contents are the content-hash key. This enables others to retrieve the file in two steps, given the signed-subspace key.

    To update a file, the owner first inserts a new version under its content-hash key, which should be different from the old version's content hash. She then inserts a new indirect file under the original signed-subspace key pointing to the updated version. When the insert reaches a node which possesses the old version, a key collision will occur. The node will check the signature on the new version, verify that it is both valid and more recent, and replace the old version. Thus the signed-subspace key will lead to the most recent version of the file, while old versions can continue to be accessed directly by content-hash key if desired. (If not requested, however, these old versions will eventually be removed from the network--see section 3.4.) This mechanism can be used to manage directories as well as regular files.

    Content-hash keys can also be used for splitting files into multiple parts. For large files, splitting can be desirable because of storage and bandwidth limitations. Splitting even medium-sized files into standard-sized parts (e.g. 2n kilobytes) also has advantages in combating traffic analysis. This is easily accomplished by inserting each part separately under a content-hash key, and creating an indirect file (or multiple levels of indirect files) to point to the individual parts.

    All of this still leaves the problem of finding keys in the first place. The most straightforward way to add a search capability to Freenet is to run a hypertext spider such as those used to search the web. While an attractive solution in many ways, this conflicts with the design goal of avoiding centralization. A possible alternative is to create a special class of lightweight indirect files. When a real file is inserted, the author could also insert a number of indirect files each containing a pointer to the real file, named according to search keywords chosen by her. These indirect files would differ from normal files in that multiple files with the same key (i.e. search keyword) would be permitted to exist, and requests for such keys would keep going until a specified number of results were accumulated instead of stopping at the first file found. Managing the likely large volume of such indirect files is an open problem.

    An alternative mechanism is to encourage individuals to create their own compilations of favorite keys and publicize the keys of these compilations. This is an approach also in common use on the world-wide web.


    Retrieving data

    To retrieve a file, a user must first obtain or calculate its binary file key. She then sends a request message to her own node specifying that key and a hops-to-live value. When a node receives a request, it first checks its own store for the data and returns it if found, together with a note saying it was the source of the data. If not found, it looks up the nearest key in its routing table to the key requested and forwards the request to the corresponding node. If that request is ultimately successful and returns with the data, the node will pass the data back to the upstream requestor, cache the file in its own datastore, and create a new entry in its routing table associating the actual data source with the requested key. A subsequent request for the same key will be immediately satisfied from the local cache; a request for a ``similar'' key (determined by lexicographic distance) will be forwarded to the previously successful data source. Because maintaining a table of data sources is a potential security concern, any node along the way can unilaterally decide to change the reply message to claim itself or another arbitrarily-chosen node as the data source.

    If a node cannot forward a request to its preferred downstream node because the target is down or a loop would be created, the node having the second-nearest key will be tried, then the third-nearest, and so on. If a node runs out of candidates to try, it reports failure back to its upstream neighbor, which will then try its second choice, etc. In this way, a request operates as a steepest-ascent hill-climbing search with backtracking. If the hops-to-live limit is exceeded, a failure result is propagated back to the original requestor without any further nodes being tried. Nodes may unilaterally curtail excessive hops-to-live values to reduce network load. They may also forget about pending requests after a period of time to keep message memory free.

    Figure 1 depicts a typical sequence of request messages. The user initiates a request at node a. Node a forwards the request to node b, which forwards it to node c. Node c is unable to contact any other nodes and returns a backtracking ``request failed'' message to b. Node b then tries its second choice, e, which forwards the request to f. Node f forwards the request to b, which detects the loop and returns a backtracking failure message. Node f is unable to contact any other nodes and backtracks one step further back to e. Node e forwards the request to its second choice, d, which has the data. The data is returned from d via e and b back to a, which sends it back to the user. The data is also cached on e, b, and a.

    Figure 1: A typical request sequence.

    This mechanism has a number of effects. Most importantly, we hypothesize that the quality of the routing should improve over time, for two reasons. First, nodes should come to specialize in locating sets of similar keys. If a node is listed in routing tables under a particular key, it will tend to receive mostly requests for keys similar to that key. It is therefore likely to gain more ``experience'' in answering those queries and become better informed in its routing tables about which other nodes carry those keys. Second, nodes should become similarly specialized in storing clusters of files having similar keys. Because forwarding a request successfully will result in the node itself gaining a copy of the requested file, and most requests will be for similar keys, the node will mostly acquire files with similar keys. Taken together, these two effects should improve the efficiency of future requests in a self-reinforcing cycle, as nodes build up routing tables and datastores focusing on particular sets of keys, which will be precisely those keys that they are asked about.

    In addition, the request mechanism will cause popular data to be transparently replicated by the system and mirrored closer to requestors. For example, if a file that is originally located in London is requested in Berkeley, it will become cached locally and provide faster response to subsequent Berkeley requests. It also becomes copied onto each computer along the way, providing redundancy if the London node fails or is shut down. (Note that ``along the way'' is determined by key closeness and does not necessarily have geographic relevance.)

    Finally, as nodes process requests, they create new routing table entries for previously-unknown nodes that supply files, increasing connectivity. This helps new nodes to discover more of the network (although it does not help the rest of the network to discover them; for that, the announcement mechanism described in section 3.5 is necessary). Note that direct links to data sources are created, bypassing the intermediate nodes used. Thus, nodes that successfully supply data will gain routing table entries and be contacted more often than nodes that do not.

    Since keys are derived from hashes, lexicographic closeness of keys does not imply any closeness of the original descriptive strings and presumably, no closeness of subject matter of the corresponding files. This lack of semantic closeness is not important, however, as the routing algorithm is based on knowing here keys are located, not where subjects are located. That is, supposing a string such as text/philosophy/sun-tzu/art-of-war yields a file key AH5JK2, requests for this file can be routed more effectively by creating clusters containing AH5JK1, AH5JK2, and AH5JK3, not by creating clusters for works of philosophy. Indeed, the use of hashes is desirable precisely because philosophical works will be scattered across the network, lessening the chances that failure of a single node will make all philosophy unavailable. The same is true for personal subspaces--files belonging to the same subspace will be scattered across different nodes.


    Storing data

    Inserts follow a parallel strategy to requests. To insert a file, a user first calculates a binary file key for it, using one of the procedures described in section 3.1. She then sends an insert message to her own node specifying the proposed key and a hops-to-live value (this will determine the number of nodes to store it on). When a node receives an insert proposal, it first checks its own store to see if the key is already taken. If the key is found, the node returns the pre-existing file as if a request had been made for it. The user will thus know that a collision was encountered and can try again using a different key. If the key is not found, the node looks up the nearest key in its routing table to the key proposed and forwards the insert to the corresponding node. If that insert causes a collision and returns with the data, the node will pass the data back to the upstream inserter and again behave as if a request had been made (i.e. cache the file locally and create a routing table entry for the data source).

    If the hops-to-live limit is reached without a key collision being detected, an ``all clear'' result will be propagated back to the original inserter. Note that for inserts, this is a successful result, in contrast to situation for requests. The user then sends the data to insert, which will be propagated along the path established by the initial query and stored in each node along the way. Each node will also create an entry in its routing table associating the inserter (as the data source) with the new key. To avoid the obvious security problem, any node along the way can unilaterally decide to change the insert message to claim itself or another arbitrarily-chosen node as the data source.

    If a node cannot forward an insert to its preferred downstream node because the target is down or a loop would be created, the insert backtracks to the second-nearest key, then the third-nearest, and so on in the same way as for requests. If the backtracking returns all the way back to the original inserter, it indicates that fewer nodes than asked for could be contacted. As with requests, nodes may curtail excessive hops-to-live values and/or forget about pending inserts after a period of time.

    This mechanism has three effects. First, newly inserted files are selectively placed on nodes already possessing files with similar keys. This reinforces the clustering of keys set up by the request mechanism. Second, new nodes can use inserts as a supplementary means of announcing their existence to the rest of the network. Third, attempts by attackers to supplant existing files by inserting junk files under existing keys are likely to simply spread the real files further, since the originals are propagated on collision. (Note, however, that this is mostly only relevant to keyword-signed keys, as the other types of keys are more strongly verifiable.)


    Trattamento dei dati

    Tutti i sistemi di conservazione delle informazioni devono tenere in considerazione il problema della capacità finita di conservare informazioni. I singoli gestori del nodo di Freenet possono configurare la grandezza dello spazio da dedicare ai loro magazzini di informazioni. La conservazione dei nodi ` trattata come una Cache LRU (Least Recently Used, ovvero usato meno di recente ndt) [29] nella quale i singoli dati sono mantenuti ordinati in ordine decrescente per data della più recente richiesta (o data di inserimento, se una voce non è mai stata richiesta). Quando arriva un nuovo file (o grazie a un nuovo inserimento o per una richiesta andata a buon fine) che potrebbe far aumentare la dimensione del magazzino di informazioni oltre la grandezza stabilita, i file usati meno di recente sono espulsi in ordine fino a che si crea lo spazio. Il risultante impatto sulla disponibilità è mitigato dal fatto che le voci della tabella di routing create quando i file espulsi sono arrivati per la prima volta rimarranno per un certo tempo, permettendo potenzialmente al nodo di procurarsi successivamente altre copie dalle fonti di dati originali. (Le voci della tabella di routing, infine, vengono anche cancellate in maniera simile quando la tabella si riempie, anche se saranno conservate più a lungo se sono più piccole.)

    A voler essere precisi, il magazzino di informazioni non è una cache, poichè l'insieme dei magazzini di informazioni sono tutte le informazioni che sono lì. Cioè, non c'è una copia ``permanente'' che viene replicata in una cache. Una volta che tutti i nodi hanno deciso, parlando collettivamente, di abbandondare un determinato file, esso non sarà più disponibile per la rete. Riguardo a ciò, Freenet è diversa dai sistemi come Eternity e Free Haven che cercano di dare garanzie sui tempi di vita dei file.

    Il meccanismo della scadenza ha un aspetto svantaggioso, comunque, poichè permette che i documenti vecchi svaniscano naturalmente dopo esser stati rimpiazzati da documenti più nuovi. Se un documento vecchio è ancora usato e considerato prezioso per ragioni storiche, resterà in vita fino a quando continuerà ad essere richiesto.

    Per ragioni politiche o legali, può essere desiderabile per gli operatori dei nodi non conoscere esplicitamente i contenuti dei loro magazzini di informazioni. E' per questo che tutti i file conservati sono criptati. Le procedure di crittazione usate non mirano a proteggere il file--questo sarebbe impossibile siccome chi fa una richiesta (potenzialmente chiunque) deve essere capace di decrittare il file una volta ricevuto. Piuttosto, la finalità è che il gestore di un nodo possa credibilmente negare ogni conoscenza del contenuto del suo magazzino di dati, poichè tutto ciò che sa a priori è la file key, non la encryption key. Le encryption keys per i dati keyword-signed e signed-subspace possono essere ottenute solo con un procedimento di reverse su un hash, e le encryption keys per i dati content-hash non sono affatto correlate. Con una certa difficoltà, naturalmente, un attacco basato sul dizionario svelerà quali keys sono presenti--poichè esso lo deve fare per le richieste per poter funzionare-- ma la fatica che un tale tentativo richiederebbe è intesa a fornire una misura di protezione per i gestori del nodo.


    Aggiungere nodi

    Un nuovo nodo può unirsi alla rete scoprendo l'indirizzo di uno o più nodi esistenti attraverso canali fuori banda, e poi incominciando a mandare messaggi. Come detto precedentemente, il meccanismo di richiesta abilita naturalmente i nuovi nodi a imparare più cose della rete nel corso del tempo. Comunque, per far scoprire questi dai nodi preesistenti, i nuovi nodi devono in qualche modo annunciare la loro presenza. Questo processo è reso complicato da due requisiti in qualche modo in conflitto. Da una parte per promuovere un routing efficiente, ci piacerebbe che tutti i nodi esistenti fossero lineari nel decidere quali keys mandare ad un nuovo nodo (cioè quale key assegnare ad esso nelle loro tabelle di routing). D'altra parte, causerebbe un problema di sicurezza se qualunque nodo potesse scegliere la routing key, il che esclude il sistema più lineare di raggiungere la coerenza.

    Usiamo un protocollo crittografico per soddisfare entrambi questi requisiti. Un nuovo nodo che si unisce alla rete sceglie un seed a caso e manda un messaggio di annuncio che contiene il suo indirizzo e l'hash di quel seed a qualche nodo esistente. Quando un nodo riceve un annuncio di un nuovo nodo, genera un seed a caso e lo XOR-a con l'hash che ha ricevuto, e calcola nuovamente un hash del risultato per creare un vincolo. Esso poi inoltra il nuovo hash a qualche nodo scelto a caso dalla sua tabella di routing. Questo processo continua fino a che le hops-to-live della comunicazione finiscono. L'ultimo nodo che riceve l'annuncio genera semplicemente un seed. Ora tutti i nodi in catena rivelano i loro seeds e la key per il nuovo nodo è assegnata come il XOR di tutti i seeds. Controllare i vincoli abilita ogni nodo a confermare che ognuno ha reso pubblici i loro seeds sinceramente. Questo produce una conseguente key scelta a caso, che non può essere influenzata da un partecipante malizioso. Ogni nodo poi aggiunge una voce per il nuovo nodo nella sua tabella di routing sotto quella key.


    Dettagli del protocollo

    Il protocollo Freenet è packet-oriented e usa messaggi self-contained. Ogni messaggio include un transaction ID cosicchè i nodi possono tracciare lo stato di inserimenti e richieste. Questo design è pensato per permettere flessibilità nella scelta del meccanismo di trasporto per i messaggi, se sia TCP, UDP, o altre tecnologie come packet radio. Per l'efficienza, i nodi che usano un canale persistente come una connessione TCP possono anche mandare messaggi multipli sulla stessa connessione. Gli indirizzi dei nodi consistono in un metodo di trasporto più un identificatore transport-specific come un indirizzo IP e un numero di porta, ad esempio tcp/192.168.1.1:19114. I nodi che cambiano indirizzo frequentemente possono anche usare indirizzi virtuali conservati sotto address-resolution keys (ARK's), che sono signed-subspace keys aggiornate per contenere il vero indirizzo corrente.

    Una transazione di Freenet inizia con un messaggio di Request.Handshake da un nodo a un altro, che specifica l'indirizzo di ritorno desiderato del nodo inviante.[*] (L'indirizzo di ritorno del mittente può essere impossibile da determinare automaticamente per il transport layer, o il mittente puo` desiderare di ricevere risposte a un indirizzo diverso da quello usato per mandare il messaggio.) Se un nodo remoto è attivo e risponde alle richieste, risponderà con una Reply.Handshake che specifica il numero di versione del protocollo che esso riesce a capire. Le handshakes vengono mantenute in memoria per qualche ora, e nelle transazioni seguenti tra gli stessi nodi durante questo tempo si potrà saltare questo passaggio.

    Tutti i messaggi contengono una transaction ID di 64-bit generata a caso, un limite di hops-to-live, e un contatore di profondità. Sebbene non si possa garantire che l'ID sia unico, la probabilità di una collisione durante il tempo della transazione tra il limitato insieme di nodi che vede è estremamente bassa. Le hops-to-live sono stabilite dalla fonte del messaggio e vengono diminuite a ogni passaggio per prevenire la possibilità che il messaggio venga inoltrato indefinitamente. Per ridurre le informazioni che una persona che tenta di attaccare può ottenere dal valore delle hops-to-live, i messaggi non terminano automaticamente quando le hops-to-live raggiungono 1 ma sono inoltrati con probabilità finite (ancora con hops-to-live 1). La profondità è aumentata ad ogni passaggio ed è usata da un nodo che risponde per stabilire un hops-to-live abbastanza alta da raggiungere un requestor. I requestor dovrebbero inizializzarlo a un piccolo valore a caso per oscurare la loro ubicazione. Come con le hops-to-live, una profondità di 1 non è automaticamente incrementata ma viene passata senza cambiamenti con probabilità finite.

    Per richiedere i dati, i nodi invianti mandano un messaggio di Request.Data specificando un transaction ID, le hops-to-live iniziali e la profondità, e una search key. Il nodo remoto cercherà la key nel suo magazzino di informazioni e se non viene trovata, inoltrerà la richiesta a un altro nodo come descritto nella sezione 3.2.

    Usando il limite di hops-to-live scelto, il nodo inviante fa partire un timer per la quantità di tempo prevista per contattare quei nodi, dopodichè supporrà un fallimento. Mentre la richiesta avviene, il nodo remoto può periodicamente mandare indietro messaggi Reply.Restart che indicano che i messaggi si sono bloccati aspettando timeouts della rete, cosicchè il nodo inviante sa di dover estendere il suo timer.

    Se la richiesta è portata a termine con successo, il nodo remoto risponderà con un messaggio Send.Data che contiene i dati richiesti e l'indirizzo del nodo che lo ha fornito (è possibile che esso sia falso). Se la richiesta non è portata a termine con successo e le sue hops-to-live sono state usate completamente cercando di soddisfarla, il nodo remoto risponderà con un NotFound?. Il nodo inviante allora decrementerà le hops-to-live del Send.Data (o del NotFound?) e lo passerà, a meno che esso sia il vero originatore della richiesta. Entrambi questi messaggi termino la transazione e lasciano ogni risorsa che occupavano. Comunque, se ci sono ancora hops-to-live rimanenti, di solito perchè la richiesta è andata verso un vicolo cieco dove non c'è nessun sentiero che non genera un loop, il nodo remoto risponderà con una Request.Continue dando il numero di hops-to-live rimanenti. Il nodo inviante allora tenterà di contattare il prossimo nodo dalla sua tabella di routing. Esso manderà anche un messaggio Reply.Restart.

    Per inserire dati, il nodo inviante invia un messaggio Request.Insert specificando un transaction ID generato a caso, un hops-to-live e profondità iniziale, e una key proposta. Il nodo remoto cercherà la key nel suo magazzino di informazioni e se non la troverà, inoltrerà l'inserzione a un altro nodo come descritto nella sezione 3.3. I timers e i messaggi Reply.Restart vengono anche usati alla stessa maniera delle richieste.

    Se l'inserzione infine genera una collisione tra key, il nodo remoto risponderà o con un messaggio Send.Data contenente i dati esistenti o con un NotFound? (se i dati esistenti non sono stati trovati, ma i riferimenti ad essi nelle tabelle di routing sono stati trovati). Se l'inserzione non incontra una collisione ma finisce i nodi con un numero di hops-to-live rimanenti diverso da zero, il nodo remoto risponderà con un Request.Continue. In questo caso, Request.Continue è un risultato di fallimento che significa che non è stato possibile contattare tanti nodi quanti sono stati richiesti. Questi messaggi verranno passati come nel caso della richiesta. Entrambi i messaggi terminano la transazione e lasciano ogni risorsa che occupavano. Comunque, se l'inserzione scade senza incontrare una collisione, il nodo remoto risponderà con un Reply.Insert, indicando che l'inserzione può andare avanti. Il nodo inviante passer` la Reply.Insert e aspetterà che i suoi predecessori inviino un Send.Insert che contenga i dati. Quando riceve i dati, lo conserverà in locale e inoltrer` il flusso Send.Insert, concludendo la transazione.

    Performance analysis

    We performed simulations on a model of this system to give some indications about its performance. Here we summarize the most important results; for full details, see [21].

    Network convergence

    To test the adaptivity of the network routing, we created a test network of 1000 nodes. Each node had a datastore size of 50 items and a routing table size of 250 addresses. The datastores were initialized to be empty, and the routing tables were initialized to connect the network in a regular ring-lattice topology in which each node had routing entries for its two nearest neighbors on either side. The keys associated with these routing entries were set to be hashes of the destination nodes' addresses. Using hashes has the useful property that the resulting keys are both random and consistent (that is, all references to a given node will use the same key).

    Inserts of random keys were sent to random nodes in the network, interspersed randomly with requests for randomly-chosen keys known to have been previously inserted, using a hops-to-live of 20 for both. Every 100 timesteps, a snapshot of the network was taken and its performance measured using a set of probe requests. Each probe consisted of 300 random requests for previously-inserted keys, using a hops-to-live of 500. We recorded the resulting distribution of request pathlengths, the number of hops actually taken before finding the data. If the request did not find the data, the pathlength was taken to be 500.

    Figure 2 shows the evolution of the first, second, and third quartiles of the request pathlength over time, averaged over ten trials.

    Figure 2: Time evolution of the request pathlength.

    We can see that the initially high pathlengths decrease rapidly over time. In the beginning, few requests succeed at all, but as the network converges, the median request pathlength drops to just six.

    Scalability

    Next, we examined the scalability of a growing network. Starting from a small network of 20 nodes initialized in the same manner as the previous section, we added new nodes over time and measured the change in the request pathlength.

    Inserts and requests were simulated randomly as before. Every five timesteps, a new node was created and added to the network by simulating a node announcement message with hops-to-live of 10 sent from it to a randomly-chosen existing node. The key assigned by this announcement was taken to be the hash of the new node's address. Note that this procedure does not necessarily imply a linear rate of network growth, but rather a linear relationship between the request rate and the growth rate. Since it seems likely that both rates will be proportional to network size (yielding an exponential growth rate in real, as opposed to simulated, time), we believe that this model is justifiable.

    Figure 3 shows the evolution of the first, second, and third quartiles of the request pathlength versus network size, averaged over ten trials.

    Figure 3: Request pathlength versus network size.

    We can see that the pathlength scales approximately logarithmically, with a change of slope near 40,000 nodes. We posit that the slope change is a result of routing tables becoming filled and could be improved by adding a small number of nodes with larger routing tables. Section 5.4 discusses this issue in more depth. Where our routing tables were limited to 250 entries by the memory requirements of the simulation, real Freenet nodes should easily be able to hold thousands of entries. Nonetheless, even this limited network appears capable of scaling to one million nodes with a median pathlength of just 30. Note also that the network was grown continuously, without any steady-state convergence period.

    Fault-tolerance

    Finally, we considered the fault-tolerance of the network. Starting with a network grown to 1000 nodes by the previous method, we progressively removed randomly-chosen nodes from the network to simulate node failures. Figure 4 shows the resulting evolution of the request pathlength, averaged over ten trials.

    Figure 4: Change in request pathlength under network failure.

    The network is surprisingly robust against quite large failures. The median pathlength remains below 20 even when up to 30% of nodes fail.


    Small-world model

    The scalability and fault-tolerance characteristics of Freenet can be explained in terms of a small-world network model[<a HREF="#Milgram">23,<a HREF="#Watts">31,<a HREF="#Huberman">22,<a HREF="#Albert">3]. In a small-world network, the majority of nodes have only relatively few, local, connections to other nodes, while a small number of nodes have large, wide-ranging sets of connections. Small-world networks permit efficient short paths between arbitrary points because of the shortcuts provided by the well-connected nodes, as evidenced by examination of Milgram's letter-passing experiment[<a HREF="#Milgram">23] and the Erdös number game cited by Watts and Strogatz[<a HREF="#Watts">31].

    Is Freenet a small world? A key factor in the identification of a small-world network is the existence of a scale-free power-law distribution of links within the network, as the tail of such distributions provides the highly-connected nodes needed to create short paths. Figure 5 shows the average distribution of links (i.e. routing table entries) in the 1000-node Freenet networks used in the previous section.

    Figure 5: Distribution of link number among Freenet nodes.

    We see that the distribution closely approximates a power law, except for the anomalous point representing nodes with filled 250-entry routing tables. When we used differently-sized routing tables, this cutoff point moved but the power-law character of the distribution remained the same.

    In addition to providing short paths, the power-law distribution also gives small-world networks a high degree of fault-tolerance. Random failures are most likely to knock out nodes from the majority that possess only a small number of connections. The loss of poorly-connected nodes will not greatly affect routing in the network. It is only when the number of random failures becomes high enough to knock out a significant number of well-connected nodes that routing performance will be noticeably affected.


    Sicurezza

    L'obiettivo primario della sicurezza di Freenet &egrave proteggere l'anonimato di coloro che richiedono o inseriscono file. Inoltre &egrave importante proteggere l'identit&agrave di coloro che fisicamente memorizzano le informazioni. Anche se chiunque pu&ograve banalmente fare in modo che un nodo memorizzi un dato file, richiedendolo attraverso quel nodo, ci&ograve che &egrave importante &egrave che quel file resti memorizzato anche presso altri nodi non identificabili, in modo che non sia possibile rimuovere il file da Freenet tentando di attaccare tutti i nodi che lo possiedono. I file debbono essere protetti dalla modifica delierata ed il sistema, infine, deve essere resistente ad attacchi di tipo denial-of-service.

    Reiter e Rubin[<a HREF="#Reiter">25] propongono un'interessante tassonomia delle propriet&agrave della comunicazione anonima su tre assi. Il primo asse &egrave rappresenta il tipo di anonimato: anonimato del mittente o del destinatario, il che significa rispettivamente che un nemico non pu&ograve identificare chi ha originato il messaggio o chi &egrave supposto riceverlo. Il secondo asse &egrave il nemico in questione: un intercettatore locale, un nodo maligno o un insieme di nodi maligni coordinati, o un server web (quest'ultimo caso non si applica a Freenet). Il terzo asse &egrave il grado di anonimato, che varia da "riservatezza assoluta" (impossibilit&agrave di rilevare il fatto che la comunicazione avviene) a "oltre ogni sospetto" (il vero mittente non ha maggior probabilit&agrave di essere identificato come tale rispetto ad altri mittenti potenziali), a "innocenza probabile" (il fatto che il vero mittente sia tale non &egrave pi&ugrave probabile del fatto che non lo sia), a "innocenza possibile", "smascherato", "smascherato con le prove" (il nemico pu&ograve dimostrare ad altri chi &egrave il mittente).

    Poich&eacute la comunicazione su Freenet non &egrave diretta a destinatari specifici, l'anonimato del ricevente pu&ograve essere interpretato come la riservatezza della chiave, ovvero il celare la chiave che viene richiesta o inserita. Purtroppo, poich&eacute l'instradamento dipende dalla conoscenza della chiave, la riservatezza della chiave non pu&ograve essere ottenuta con lo schema Freenet di base (vedi per&ograve la discussione sul 'pre-routing' pi&ugrave sotto). L'uso di funzioni hash come chiavi permette di difendersi contro l'intercettazione casuale, ma &egrave vulnerabile ad attacchi a dizionario poich&eacute la versione originale della chiave deve essere nota per poter essere utile.

    Le propriet&agrave di anonimato di Freenet sulla base di questa tassonomia sono illustrate nella tabella 1.

    Table 1: Propriet&agrave di anonimato in Freenet.
    Sistema Nemico Anonimato del mittente Riservatezza della chiave
    Schema Freenet di base intercettatore locale smascherato smascherato
    insieme di nodi maligni oltre ogni sospetto smascherato
    Freenet + pre-routing intercettatore locale smascherato oltre ogni sospetto
    insieme di nodi maligni oltre ogni sospetto smascherato


    Contro un insieme di nodi maligni, l'anonimato del mittente &egrave preservato oltre ogni sospetto poich&eacute un nodo sul percorso di richiesta non &egrave capace di riconoscere se il nodo che lo precede ha originato la richiesta o la sta semplicemente inoltrando. [<a HREF="#Reiter">25] descrive un attacco di tipo probabilistico che potrebbe compromettere l'anonimato del mittente, effettuando un'analisi statistica della probabilit&agrave che una richiesta che arriva al nodo a sia inoltrata o gestita direttamente e della probabilit&agrave che a scelga un particolare nodo b per inoltrare la richiesta. Tale analisi non &egrave comunque applicabile direttamente a Freenet, poich&eacute i percorsi di richiesta non sono costruiti in modo stocastico. L'inoltro della richiesta dipende dal fatto che a abbia o meno il dato richiesto nel datastore pi&ugrave che da fattori random. Se una richiesta viene inoltrata, le tabelle di instradamento determinano dove questa viene inviata e potrebbe essere il caso che a inoltri tutte come nessuna richiesta a b. In ogni caso, il valore di "depth" pu&ograve fornire alcune indicazioni sulla distanza del nodo di origine, anche se &egrave nascosta dalla selezione casuale della "depth" iniziale e del suo incremento condotto in modo randomico (vedi paragrafo 4). Considerazioni simili si possono applicare agli "hops-to-live". Saranno necessari ulteriori studi per chiarire queste questioni.

    Non vi &egrave protezione dei messaggi contro l'intercettazione sul percorso tra l'utente e il primo nodo. Poich&eacute il primo nodo pu&ograve agire da intercettatore, si raccomanda che l'utente impieghi un nodo sulla propria macchina come punto d'entrata sulla rete Freenet. I messaggi tra nodi successivi sono crittati contro l'intercettazione, ma &egrave comunque possibile effettuare un'analisi del traffico (ad esempio si pu&ograve osservare un messaggio uscente senza un precedente messaggio entrante e concludere che quel messaggio &egrave stato generato localmente).

    La riservatezza delle chiavi ed una pi&ugrave forte protezione dell'anonimato del mittente possono essere ottenute introducendo un ``pre-routing'' dei messaggi del tipo di quello utilizzato in mix. In questo schema, i messaggi Freenet di base vengono crittati con una sequenza di chiavi pubbliche che determinano il percorso che il messaggio seguir&agrave (bypassando il normale meccanismo di instradamento). I nodi lungo il percorso non possono determinare n&eacute il mittente del messaggio n&eacute il suo contenuto (inclusa la chiave di richiesta), come nel caso di mix. Quando il messaggio raggiunge il punto terminale della fase di pre-routing, esso viene inserito nella rete Freenet e si comporta come se fosse stato originato localmente.

    La protezione per la sorgente dei dati &egrave assicurata dalla riscrittura occasionale del campo sorgente nelle risposte. Il fatto che un nodo sia indicato come sorgente per una data chiave non implica necessariamente che esso abbia effettivamente fornito i dati, o che sia anche stato contattato nel corso della richiesta. Non &egrave possibile decidere se il nodo a valle abbia fornito il file o abbia semplicemente inoltrato una richiesta generata da qualcun altro. Infatti, il solo richiedere con successo un file fa in modo che questo venga memorizzato nel nodo a valle se non c'era di gi&agrave, cosicch&eacute un successivo esame di quel nodo non rivela niente sullo stato precedente, e fornisce una base legale per affermare che un certo dato non era presente prima che venisse richiesto all'atto dell'investigazione. La richiesta di un dato con un "hops-to-live" di 1 non rivela direttamente se il nodo avesse precedentemente memorizzato il dato, poich&eacute continuano con probabilit&agrave finita ad inoltrare messaggi con hops-to-live pari ad 1. La conclusione con successo di un consistente numero di richieste di file correlati pu&ograve fornire tuttavia una base per sospettare che tali file si trovassero memorizzati localmente in precedenza.

    La modifica di un file da parte di un nodo maligno che si trovi sulla catena di richiesta costituisce una grave minaccia, e non solo per l'integrit&agrave del file in s&eacute. Poich&eacute le tabelle di instradamenteo sono basate sulle risposte alle richieste, un nodo potrebbe tentare di indirizzare il traffico verso se stesso facendo finta di possedere file che non ha e rispondendo semplicemente con dati fittizi. Per dati memorizzati sotto chiavi content-hash o signed-subspace, questo non &egrave attuabile poich&eacute dati non autentici possono essere rilevati, a meno che un nodo non trovi una coincidenza di hash od abbia successo nel contraffare una firma crittografica. I dati memorizzati sotto chiavi keyword-signed sono comunque vulnerabili ad attacchi a dizionario, poich&eacute possono essere firmati da chiunque conosca la stringa descrittiva originale.

    Infine, si pu&ograve prevedere un certo numero di attacchi di tipo denial-of-service. La minaccia pi&ugrave grave &egrave che un utente cerchi di saturare la capacit&agrave di memorizzazione della rete con l'inserimento di grandi quantit&agrave di dati non significativi. Un'interessante possibilit&agrave di contrastare questi attacchi &egrave l'uso di schemi come l'Hash Cash [<a HREF="#Hash">20]. Fondamentalmente, questo schema richiede che colui che inserisce un dato debba effettuare un'elaborazione complessa come ``tassa'' per l'inserimento, in modo da rallentare l'attacco. Un'altra alternativa &egrave quella di suddividere il datastore in due parti, una per i nuovi inserimenti ed una per i file ``stabili'', che hanno cio&egrave gi&agrave ricevuto un certo numero di richieste. I nuovi inserimenti possono solo rimpiazzare altri file ``nuovi''. In questo modo, l'inserimento massiccio di dati non significativi pu&ograve solo paralizzare temporaneamente le operazioni di inserimento, ma non causare la rimozione di file importanti. Risulta infatti difficile ``legittimare'' artificialmente i dati mediante ripetute richieste, poich&eacute tutte le richieste verranno soddisfatte dal primo nodo contenente i file e non procederanno oltre. D'altra parte, non &egrave possibile interrogare direttamente i nodi a valle poich&egrave non se ne conosce l'identit&agrave. In ogni caso, l'adozione di questo schema pu&ograve compromettere la sopravvivenza di dati legittimi per un tempo lungo abbastanza da renderli stabili.

    Si pu&ograve tentare di rimpiazzare file esistenti inserendo versioni diverse di essi sotto le stesse chiavi. Questo tipo di attacco non &egrave possibile per chiave content-hash o signed-subspace, poich&eacute richiede una coincidenza di hash o la falsificazione di una firma crittografica. Un attacco di questo tipo contro una chiave keyword-signed, d'altra parte, pu&ograve portare alla coesistenza delle due versioni nella rete. Le modalit&agrave con cui i nodi trattano le collisioni (vedi descrizione dettagliata nel paragrafo 3.3) sono tali da rendere questi attacchi pi&ugrave difficili. Il successo di un attacco a rimpiazzo pu&ograve essere misurato con il rapporto tra il numero di versioni originali del file e il numero di versioni corrotte presenti nel sistema. In ogni caso, maggiore &egrave il numero di copie corrotte che si tenta di diffondere (impostando un alto hops-to-live nell'inserimento), maggiore &egrave la probabilit&agrave che si realizzi una collisione, il che causa l'incremento del numero di copie originali.

    Conclusioni

    La rete Freenet fornisce un affidabile mezzo di memorizzazione e recupero anonimo di informazioni. Mediante l'uso di nodi cooperanti diffusi su molti computer insieme ad un efficiente algoritmo adattativo di instradamento, essa mantiene anonima e disponibile l'informazione mantenendo un'alta scalabilit&agrave. La fase di test sta avendo fino ad ora un discreto successo, con decine di migliaia di copie del software scaricate e molti file in circolazione. A causa della natura anonima del sistema, &egrave impossibile decidere con esattezza quanti utenti vi siano o quali siano le prestazioni dei meccanismi di inserimento e richiesta, ma le impressioni sono state finora positive. Stiamo lavorando sulla realizzazione di un sistema di simulazione e visualizzazione che permetter&agrave di effettuare prove pi&ugrave rigorose sul protocollo e sul meccanismo di instradamento. &Egrave necessaria nna simulazione pi&ugrave &egrave realistica che tenga conto degli effetti di nodi che entrano ed escono dalla rete, della variazione della capacit&agrave e della larghezza di banda dei nodi, e di dimensioni maggiori della rete. Sarebbe inoltre desiderabile realizzare una struttura a chiave pubblica per l'autenticazione dei nodi in modo da creare un meccanismo di ricerca.

    Ringraziamenti

    Questo materiale &egrave basato parzialmente su lavori patrocinati da una National Science Foundation Graduate Research Fellowship.

    Bibliografia

    1.
    S. Adler, ``The Slashdot effect: an analysis of three Internet publications,'' Linux Gazette issue 38, March 1999.

    2.
    Akamai, http://www.akamai.com/ (2000).

    3.
    R. Albert, H. Jeong, and A. Barabási, ``Error and attack tolerance of complex networks,'' Nature 406, 378-382 (2000).

    4.
    American National Standards Institute, American National Standard X9.30.2-1997: Public Key Cryptography for the Financial Services Industry - Part 2: The Secure Hash Algorithm (SHA-1) (1997).

    5.
    R.J. Anderson, ``The Eternity service,'' in Proceedings of the 1st International Conference on the Theory and Applications of Cryptology (PRAGOCRYPT '96), Prague, Czech Republic (1996).

    6.
    Anonymizer, http://www.anonymizer.com/ (2000).

    7.
    O. Berthold, H. Federrath, and S. Köpsell, ``Web MIXes: a system for anonymous and unobservable Internet access,'' in Proceedings of the Workshop on Design Issues in Anonymity and Unobservability, Berkeley, CA, USA. Springer: New York (2001).

    8.
    D.L. Chaum, ``Untraceable electronic mail, return addresses, and digital pseudonyms,'' Communications of the ACM 24(2), 84-88 (1981).

    9.
    Y. Chen, J. Edler, A. Goldberg, A. Gottlieb, S. Sobti, and P. Yianilos, ``A prototype implementation of archival intermemory,'' in Proceedings of the Fourth ACM Conference on Digital Libraries (DL '99), Berkeley, CA, USA. ACM Press: New York (1999).

    10.
    B. Chor, O. Goldreich, E. Kushilevitz, and M. Sudan, ``Private information retrieval,'' Journal of the ACM 45(6), 965-982 (1998).

    11.
    Church of Spiritual Technology (Scientology) v. Dataweb et al., Cause No. 96/1048, District Court of the Hague, The Netherlands (1999).

    12.
    I. Clarke, ``A distributed decentralised information storage and retrieval system,'' unpublished report, Division of Informatics, University of Edinburgh (1999). Available at http://www.freenetproject.org/ (2000).

    13.
    L. Cottrell, ``Frequently asked questions about Mixmaster remailers,'' http://www.obscura.com/~loki/remailer/mixmaster-faq.html (2000).

    14.
    R. Dingledine, M.J. Freedman, and D. Molnar, ``The Free Haven project: distributed anonymous storage service,'' in Proceedings of the Workshop on Design Issues in Anonymity and Unobservability, Berkeley, CA, USA. Springer: New York (2001).

    15.
    Distributed.net, http://www.distributed.net/ (2000).

    16.
    D.J. Ellard, J.M. Megquier, and L. Park, ``The INDIA protocol,'' http://www.eecs.harvard.edu/~ellard/India-WWW/ (2000).

    17.
    Gnutella, http://gnutella.wego.com/ (2000).

    18.
    I. Goldberg and D. Wagner, ``TAZ servers and the rewebber network: enabling anonymous publishing on the world wide web,'' First Monday 3(4) (1998).

    19.
    D. Goldschlag, M. Reed, and P. Syverson, ``Onion routing for anonymous and private Internet connections,'' Communications of the ACM 42(2), 39-41 (1999).

    20.
    Hash Cash, http://www.cypherspace.org/~adam/hashcash/ (2000).

    21.
    T. Hong, ``Performance,'' in Peer-to-Peer, ed. by A. Oram. O'Reilly: Sebastopol, CA, USA (2001).

    22.
    B.A. Huberman and L.A. Adamic, ``Growth dynamics of the world-wide web,'' Nature 401, 131 (1999).

    23.
    S. Milgram, ``The small world problem,'' Psychology Today 1(1), 60-67 (1967).

    24.
    Napster, http://www.napster.com/ (2000).

    25.
    M.K. Reiter and A.D. Rubin, ``Anonymous web transactions with Crowds,'' Communications of the ACM 42(2), 32-38 (1999).

    26.
    The Rewebber, http://www.rewebber.de/ (2000).

    27.
    M. Richtel and S. Robinson, ``Several web sites are attacked on day after assault shut Yahoo,'' The New York Times, February 9, 2000.

    28.
    J. Rosen, ``The eroded self,'' The New York Times, April 30, 2000.

    29.
    A.S. Tanenbaum, Modern Operating Systems. Prentice-Hall: Upper Saddle River, NJ, USA (1992).

    30.
    M. Waldman, A.D. Rubin, and L.F. Cranor, ``Publius: a robust, tamper-evident, censorship-resistant, web publishing system,'' in Proceedings of the Ninth USENIX Security Symposium, Denver, CO, USA (2000).

    31.
    D. Watts and S. Strogatz, ``Collective dynamics of `small-world' networks,'' Nature 393, 440-442 (1998).

    32.
    Zero-Knowledge Systems, http://www.zks.net/ (2000).


    Note
    ...4<a NAME="foot15" HREF="#tex2html1">[*]
    Il lavoro di Theodore W. Hong &egrave supportato da alcuni grants da parte di the Marshall Aid Commemoration Commission and the National Science Foundation.

    ... sending<a NAME="foot128" HREF="#tex2html7">[*]
    Ricorda che il nodo a monte pu&ograve o meno essere il richiedente originale.


    About this document ...

    Freenet: A Distributed Anonymous Information Storage and Retrieval System

    This document was generated using the LaTeX2HTML translator Version 99.2beta6 (1.42)

    Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
    Copyright © 1997, 1998, 1999, Ross Moore, Mathematics Department, Macquarie University, Sydney.

    The command line arguments were:
    latex2html -split 0 -nofootnode -nonavigation -local_icons -dir icsi theoppr.tex

    The translation was initiated by Theodore Hong on 2001-01-16



    Theodore Hong

    Topic ICSI . { View | Diffs | r1.3 | > | r1.2 | > | r1.1 | More }
    Revision r1.1 - 21 Jan 2002 - 09:57 GMT - MarcoCalamari
    Revision r1.3 - 02 Feb 2002 - 15:22 GMT - MarcoCalamari
    This website is distributed under the GNU Documentation License