Sto seguendo le proposte per la “Internet 2.0”, ovvero per il superamento del paradigma attuale (connection based) e tra le proposte piu’ interessanti, ovvero tra i successori che ricevono piu’ “hype” dalla Rete attuale, c’e’ NDN, Named Data Networking. Vorrei spendere due parole, perche’ si tratta di trasformare, di fatto, internet in una gigantesca rete P2P, controllata pero’ dagli ISP. A mio avviso l’ “hype” e’ un tantino esagerato.
Potete leggere piu’ dettagli qui: http://named-data.net/
Di che cosa si tratta? Si tratta di un consorzio di universita’ e di grosse aziende, che ha proposto un nuovo protocollo di rete alternativo al WEB , tra cui Cisco, universita’ come UCLA, e altre universita’ (tra cui spicca l’universita’ di Roma e Padova, come utilizzatori di fase avanzata -potevate fare un pochino di piu’, eh? Farsi battere dai franchi sulla rete, diocan!) , qui trovate l’elenco dei partecipanti: http://named-data.net/project/participants/
Il motivo per il quale lo trovo interessante, oltre alla levatura dei partecipanti, e’ che sono arrivati ad una fase di testbed, ovvero c’e’ una rete internazionale che lavora usando questo protocollo, e che sta eseguendo dei test reali su vasta scala. http://ndnmap.arl.wustl.edu/
Esistono anche programmi basati su questa rete? Si, esistono: http://named-data.net/codebase/applications/
Adesso andiamo a vedere di cosa si tratta.
Nella rete attuale qualcuno (ch viene detto client) inizia una connessione verso una porta qualsiasi di un server, il quale gli fornisce dei contenuti , scritti dentro un pacchetto che torna indietro basandosi sull’informazione scritta nell’header, ovvero le informazioni che vengono scambiate avendo come “garanzia” e come “contratto” quella di andare da una data sorgente ad un dato destinatario.
Non c’e’ invece alcun contratto riguardante il payload: il contenuto del pacchetto e’ completamente arbitrario.
Quindi, quando leggete questo blog, dovete innanzitutto essere sicuri di poterlo raggiungere, poi mandate un pacchetto che chiede, in generale “dammi la homepage – GET / , host:www.keinpfusch.net ” e poi leggendo la homepage , quando cliccate, il browser manda un altro pacchetto con scritto “GET /articoloqualsiasi host:www.keinpfusch.net”
Il pacchetto viene “imbustato” con una sorgente ed una destinazione, che contengono l’indirizzo IP del sorgente e del destinatario.
NDN invece non funziona cosi’, ed e’ piu’ simile ad una darknet basata su hashtable, come Gnutella o i2p.
In questa rete, se volete avere http://keinpfusch.net/p/FAQ.html non fate altro che inviare un pacchetto che richiede IL CONTENUTO, al vostro router.
Per identificare il contenuto chiedete il suo hash, cioe’
c24f74f78641ad5cae887f112e07e2bd950b4802
Il pacchetto viene ricevuto da un router, che lo mette in coda , e poi piano piano chiede in giro “chi ha il contenuto c24f74f78641ad5cae887f112e07e2bd950b4802” ?
Questa richiesta si chiama “interesse”; come quando andate in biblioteca e chiedete il libro che volete usando un ISBN, insomma.
A questo punto, CHIUNQUE abbia quel contenuto , in cache o meno, puo’ rispondere e farvelo avere. Il che equivale ad una rete con la CDN incorporata , ovvero parte del trasporto in se’.
Come fate a sapere che quel contenuto sia proprio quello che volete avere? Come fate a leggere l’hash? Ci sono due meccanismi di sicurezza: la prima e’ la signature del contenuto, ovvero il fatto che voi possiate essere “relativamente” certi di leggere quel che volete, verificando la signature.
Tutto, insomma, si basa sulle autorita’ di certificazione, oppure su certificati selfsigned, se i router si degnano di trasportare contenuti con certificati selfsigned, ma della “liberta’” di questa rete parleremo dopo.
Chi invece manda la richiesta di interesse non ha modo di identificarsi. In questo modo il server non sa mai con chi sta parlando, ammesso che venga raggiunto.
Il modo in cui si e’ certi di rraggiungere la sorgente e’ settare nel pacchetto un apposito campo “Must-Be-Fresh”. In tal caso, siccome stiamo chiedendo un contenuto fresco,e l’unico modo possibile per esserne certi e’ di chiederlo alla sorgente, la richiesta arriva alla sorgente, OPPURE qualcuno si fa intermediario e chiede alla sorgente se il pacchetto che ha in cache sia ancora fresco. Il pacchetto di dati, del resto, ha un campo Freshness period, per cui non c’e’ nemmeno un grosso bisogno di chiedere continue conferme.
E le rotte? L’idea e’ che il pacchetto torna indietro seguendo esattamente il percorso fatto dal pacchetto di richiesta di interesse, introducendo cosi’ un pesantissimo paradigma di commutazione di circuito in una rete nata per fare commutazione di pacchetto. Questo tuttavia e’ necessario per garantire l’ordine dei pacchetti: se una volta manifestato un interesse alla rete il vostro contenuto vi arriva in ordine sparso, come succede quando scaricate un torrent, se parliamo di un documento o di una pagina la cosa puo’ andar bene, se parliamo di servizi interattivi (immaginate un ssh fatto cosi’) le cose si complicano alquanto.
Tutto questo, pero’, non e’ per nulla nuovo: si tratta di quello che fanno le reti basate su torrent , che identificano con un hash un dato contenuto, si occupano di fare da tracker o di usare altri meccanismi di distributed hash, in modo da identificare i contenuti e trovarli.
In pratica, hanno reinventato i2p + torrent, e ne hanno fatto una proposta istituzionale.
Adesso voi direte: ma fico! Se tutta internet diventa una darknet, siamo a posto! E chi ci ammazza piu’ a noi? Privacy! Liberta! Motocicletta e vento nei capelli!
Non esattamente. La trappola consiste nel fatto che il router viene programmato dall’ISP per gestire i contenuti. Il fatto che il trasporto sia content-based significa essenzialmente che, identificato il contenuto, lo si puo’ mettere in blacklist a livello di trasporto.
Diciamo che io voglia dire “Kim il sung me lo puppa”. Questa cosa ha un hash , ae474c6200aeca1e19ff62c3a0c3720b50a0a929 . Siccome il router sa di preciso quale contenuto maneggia, io posso dire a tutti i router della nazione di bloccare ogni richiesta di interesse per ae474c6200aeca1e19ff62c3a0c3720b50a0a929.
In tal caso, nessuno riuscira’ mai piu’ a vedere nessun contenuto che contenga “Kim il sung me lo puppa”.
La rete darknet, cioe’, funziona perche’ nessuna autorita’ controlla i router. Se il routing fosse sotto controllo, per bloccare i2p basterebbe bannare alcune chiavi.
Di fatto, cioe’, e’ perfetto per l’industria dell’intrattenimento, e per servizi come netflix e spotify.
- Il contenuto ha una signature ed un validity period. Dopodiche’ scompare da internet a meno di non recuperarlo dalla sorgente.
- Posso chiedere ai provider di bloccare tutti i contenuti xvz che non abbiano la mia chiave specifica, o di controllare presso di me quale dovrebbe essere la chiave specifica del mio contenuto.
- Posso bloccare la copia illegale identificadone l’hash e chiedendo ai router di non propagare richieste di interesse ne’ il contenuto stesso.
- Tutta la rete si comporta come una CDN, aggratise.
- Il contenuto piu’ visto prevale , dal momento che e’ in cache ovunque. Vince sempre chi fa numeri piu’ grandi.
e’ abbastanza chiaro, cioe’, chi stia finanziando tale progetto.
Andiamo pero’ a vedere i cons:
- I servizi interattivi a bassa latenza sono intralciati dalle code e dal fatto che se un router si spegne per manutenzione, interrompe tutti i circuiti prestabiliti senza che siano possibili altri percorsi di ritorno.
- E’ necessario che il client conosca in anticipo il contenuto da scaricare. Questo puo’ avvenire attraverso un URN (il cui schema e’ definito dal progetto) ma da quel momento il nome del prossimo chunk deve essere gia’ in ogni pacchetto.
- La frammentazione deve essere gestita da uno schema simile a UDHI, e loro hanno in effetto scelto uno schema TLV. Giusto, ma l’unica garanzia dell’ordine dei pacchetti e’ la chiusura del circuito o il loro riassemblaggio in coda, che inevitabilmente produce altre latenze.
- Permette la censura, ovvero dato un contenuto, posso chiedere ai carrier di non farlo passare bloccando le richieste di interesse. Siccome lo smaltimento delle code di tali richieste e’ gia’ parte del protocollo, il costo aggiuntivo per la censura e’ nullo.
- Fa perdere il controllo sul contenuto al proprietario. Certo, sul pacchetto c’e’ un campo che vi parla della sua freschezza, ma la prima cosa che faranno i produttori e’ di non esporre l’ ISP a contenuti con validita’ troppo alta o troppo bassa, e quindi andranno a manipolare quel campo a piacimento, come avviene per gli SMS.
- Non e’ chiaro il meccanismo di risoluzione delle race conditions.
- Come sempre quando si parla di Cisco, si e’ introdotto un Limite Arbitrario ad Capocchiam di Minchia, che e’ di 4 bytes per suffisso per ogni contenuto. Significa che un contenuto puo’ essere letto al massimo da 4 miliardi di richieste, ma siccome le richieste sono generate in maniera asincrona dal client a spasso per il mondo, il pericolo di collisioni diventa altissimo , a seconda dell’algoritmo usato per generare il suffisso.
- La sicurezza e’ illusoria. Se io faccio una connessione ssh non faccio altro che inviare una richiesta di interesse per un certo urn (ssh://qualcosa.qualcosaltro ) e metto un suffisso. A quel punto se un altro ente fa richiesta per lo stesso URN con lo stesso suffisso, il router fornira’ il pacchetto ad entrambi. E’ solo questione di indovinare il suffisso. Ma siccome sono solo 4 bytes per il suffisso, e un pacchetto ha una dimensione attorno ai 300 Bytes, sono circa 1.2 TB di dati , che pero’ si distribuiscono su tutta la rete, nella speranza di beccare un router che abbia il pacchetto in coda. La pesca a strascico diventa possibile a chiunque sia sul backbone.
- La sicurezza e’ illusoria, due: posso ordinare ai miei router di ignorare il controllo di coerenza tra URN e signature, risparmiando un sacco di CPU. Il 50% degli MVNO e degli ISP lo fara’. In tal caso si apre la porta ai contenuti selfsigned, e chiunque puo’ creare una vera darknet a patto di scrivere un client apposito.
- La sicurezza e’ IMPOSSIBILE: chi riceve una richiesta di interesse non sa da chi sia partita, perche’ conosce solo il circuito. I pacchetti non contengono ne’ sorgente ne’ destinatario, e il circuito lo conosci solo per l’ultimo tratto. A meno di non possedere fisicamente la rete end to end.
- Non c’e’ modo di fare push di contenuti. Se io voglio scaricare il contenuto so come fare, ma se io voglio mandare un contenuto a qualcuno, devo aspettare che faccia una specifica richiesta di interesse. Non e’ una rete internet, e’ una TV via cavo ove gli abbonati mostrano interesse per il film che vogliono.
per quanto vale la mia opinione, questa roba fallira’. Fallira’ perche’ e’ troppo evidentemente un tentativo di trasformare Internet in una TV via cavo, a benefico di alcuni player e di alcuni business (che evidentemente finanziano l’impresa) ma non tiene conto del fatto che non possiamo mandare un’email sino a quando qualcuno non ha fatto una richiesta di interesse per questa email, non possiamo mandare un pacchetto di chat sino a quando qualcuno non ha fatto una richiesta di interesse, non possiamo telefonare a qualcuno se questo qualcuno non ha fatto una richiesta di interesse per la nostra telefonata.
A meno di non inventare una richiesta di interesse per l’apertura della comunicazione, (ma non vedo delle specifiche simili) , che causino poi un handshake fatto cosi’:
- Mi interessa l’urn “telefoniamoci:004912345678”
- La rete trova il vostro cellulare che risponde “ecco il nuovo hash per la telefonata”
- Adesso fate una nuova richiesta di interesse per quello specifico hash.
la cosa e’ abbastanza delirante, nel senso che abbiamo reinventato il balletto SYN, SYN ACK, ACK , senza introdurre alcun miglioramento. A questo punto abbiamo di nuovo creato una macchina a stati, trasformato internet in una serie di reti a commutazione di circuito perdendo vantaggi, abbiamo una possibilita’ di censura piu’ alta, ma non si vedono i vantaggi, se non per quei settori dell’industria che amano la TV via cavo abbastanza da volere una intera internet fatta cosi’.
PEr questo credo che fallira’: il WEB e’ nato da un ente accademico, e per questo indipendente. Non era finanziato da questa o quella lobby a favore dei propri interessie a sfavore di altri interessi.
Nel momento in cui abbiamo fatto Hollywood Lobbies Data Networking, chiunque non sia una lobby di hollywood scuotera’ la testa e vi ridera’ in faccia.
Del resto, stiamo parlando di “Cisco che inventa un nuovo protocollo che prendera’ il posto di tutto l’esistente”.Come finisce lo sappiamo gia’.
