"The internet of things", cioe' il nome commerciale del cosiddetto M2M (Machine to Machine) rivolto al mondo consumer (nel mondo corporate va sotto il nome di "Industrial Internet") sta facendo gridare molta gente allo scandalo, come ha fatto di recente Sterling quando dice che si sta andando verso un nuovo totalitarismo. Personalmente NON approvo questo approccio, per alcune ragioni.
Chi fa queste predizioni commette diversi errori, cioe' parte dall'ipotesi che tutte queste cose arrivino nelle case SENZA che l'infrastruttura di internet debba cambiare. Essi cioe' continuano ad immaginare la internet attuale , e specialmente l'attuale modello di sviluppo e il modello di protocolli odierni, cioe' il concetto di "client-server".
Il problema pero' e' che , se andiamo a vedere i numeri, nessuno di questi modelli e' sostenibile sul serio, neppure dal punto di vista dell'indirizzamento. E con modelli del genere le "dittature" sarebbero cosi' ricattabili da essere piu' gli underdog che altro.
Immaginiamo dunque che , nei prossimi dieci anni, qualcosa come 15 miliardi di dispositivi (ed e' un'assunzione ottimistica) entrino in rete. Innanzitutto, sara' necessario un cambio radicale nei protocolli di rete. IPv4 in queste condizioni non basta (e gli AS sono gia' esauriti) per cui occorrera' passare ad IPv6.
Il guaio di IPv6 e' di due tipi.Il primo e' la sua estendibilita' infinita. La capacita' di IPv6 di descrivere il payload - di fatto un layer di presentazione - a livello di trasporto fa si' che sia possibile crittografare a livello nativo, senza per questo dover creare una rete virtuale o un layer di trasporto come SSL.
Ma la cosa e' vera anche al contrario: se da qualche parte c'e' un router che accetta di girare il mio traffico, posso costruire una rete "locale" usando macchine sparse in ogni parte del mondo. In definitiva , cioe', l'implementatore di una darknet non deve fare altro che costruire un "normale" router IPv6, e decidere come criptare il traffico. E sono possibili reti "dark" praticamente di ogni dimensione: poiche' IPv6 contiene di per se' il layer di presentazione - gli extension Header ( http://en.wikipedia.org/wiki/IPv6_packet#Extension_headers ) - di fatto e' possibile creare l'equivalente di una "vpn distribuita" semplicemente distribuendo chiavi di crittazione e mettendo su uno o piu' router. Non servono indirizzi diversi, non serve niente di niente che un software capace di implementare gli algoritmi per la crittazione.
La ragione per la quale IPv6 si sta diffondendo molto "lontano da NSA" , prevalentemente in paesi che non ne hanno gradita l'invadenza, mentre viene misteriosamente osteggiata nei paesi "servi" degli USA, dovrebbe gia' far capire quanto sia pericolosa questa cosa. In queste condizioni, per intenderci, OGNI macchina della rete non solo e' un possibile vpn client, come ora, ma con le stesse identiche funzionalita' agisce da concentratore VPN. In definitiva, il fatto di non necessitare di una differente topologia della rete (cioe' di dedicare nuovi indirizzi sulle interfacce della VPN) , di non dover cambiare necessariamente la rotta, crea una specie di VPN P2P. L'incubo delle polizie di tutto il mondo: una chatroom che diventa una rete a se'.
Adesso immaginate la cosa nella "internet of things": il manufacturer che fa il suo frigorifero puo' semplicemente dire che si, controlla le statistiche sul frigo, ma se in Europa non si comprano frigoriferi americani, per gli USA quegli elettrodomestici "scompaiono" dalla rete perche' si creano la propria rete.
Questo e' chiaro se leggete le specifiche di IPv6-Mobile. Nel creare un IPv6 che si adattasse ai meccanismi ed alle necessita' della rete mobile, si sono inventate diverse estensioni. Una di queste e' il porting di IPv6 di CoA, "Care of Address", specialmente nella versione di FACoA, ovvero di Foreign Address CoA. In questa configurazione, il vostro dispositivo mobile (un drone, un robot, un'automobile, quelchele) si tengono si il proprio IPv6 , ma espongono di volta in volta un ip della rete ove si loggano.
Sebbene questo sia necessario solo in IPv4, vista la topologia della rete basata su broadcast (o sei nel broadcast o non ti giro il traffico) , la sua implementazione e' stata portata ad IPv6. Da questo punto di vista, cioe', un dispositivo mobile (e moltissimo del M2M avviene in wireless) si limita a conservare il proprio IP di fabbrica, ma quando e' fuori dalla sua home network prende un indirizzo esteriore legato al suo nuovo ISP, a patto pero' di comportarsi internamente come un NAT per l'indirizzo di fabbrica.
Questo, unito a quanto ho scritto sul payload criptato in forma nativa nel pacchetto IP, per il sorvegliante e' un vero e proprio incubo. E' vero che per la sorveglianza domestica NON cambia molto, anzi, si puo' comunque avere traccia di entrambi gli IP : il guaio e' che quando si vuole sorvegliare qualcun altro, la geometria della sua rete diventa quasi impossibile da determinare.
Vediamo di fare un esempio: Google vi da' android, il quale ha il suo IP nativo, e inizia a chiacchierare con la casa madre. I dati del vostro frigorifero android pero' fanno gola al vostro governo. Siccome il frigorifero android assumera' un IP della rete ove e' connesso, come gia' accade con IPv4, ma conservera' l' IP originario , e' assolutamente semplice per l' ISP dire "questo oggetto cerchera' di comunicare con Google".
Voi penserete che questo dia ancora piu' POTERE all' ISP, e vi rispondero' che pero' toglie potere a Google, ma per estendere il concetto possiamo dire questo. Dividiamo la sorveglianza in due branche:
- Sorveglianza domestica: quella che una nazione fa sul proprio territorio.
- Sorveglianza internazionale: l'uso di internet per sorvegliare utenti all'estero.
il legame tra le due cose c'e', ma e' INVERSO. Quando un governo (es: Cina) sorveglia MOLTO bene la propria rete domestica, e' difficilissimo sorvegliarli dall'esterno. Google e Facebook fanno un'estrema fatica a raccogliere dati in Cina, per dire. E dal momento che il governo cinese sorveglia molto la rete, per NSA e' molto difficile operare indisturbata.
La sorveglianza domestica, cioe', ha un lato positivo, perche' a seconda della scelta del governo, puo' diventare PROTEZIONE dei sistemi domestici. Sorvegliare qualcuno puo' servire per spiarlo, ma anche per proteggerlo.
A questo punto abbiamo due cose di IPv6 che sono pericolose per NSA:
- Se la rete bersaglio e' tutta dentro ad una nazione, proteggerla e' estremamente facile usando i layer di presentazione a livello IP (e non piu' tcp) degli extension header. Un governo puo' imporre la crittazione con un proprio algoritmo a tutta la nazione, a costi di implementazione relativamente piu' bassi rispetto ad IPv4. In questo senso, usando IPv6 il controllo della rete domestica e' piu' semplice, specialmente per i dispositivi mobili. Posso impedire quando voglio che uno specifico dispositivo comunichi con google maps la sua posizione, semplicemente assegnandogli - riconoscendolo attraverso la parte fissa dell'indirizzo - un FACoA che non parla con google maps. E' possibile anche con Ipv4, ma richiede un ridesign della rete. IPv6 lo rende molto meno COSTOSO.
- Se la rete bersaglio e' multinazionale, e' difficile per i governi proteggerla, ma possono a quel punto proteggersi gli utenti, creando reti segrete mediante il layer di presentazione. Poiche' tutto avviene a livello IP, e' MOLTO MENO COSTOSO creare una intranet multinazionale basata su VPN. Una specie di VMPLS gia' embedded nel protocollo.
Sia chiaro: il problema non e' di features, ma di costi. Potete fare questa cosa con IPv4, ma dovete fare subnetting, dovete poi cambiare topologia alla rete, piazzare firewall, , mettere concentratori vpn. Su IPv6, potete semplicemente decidere che , dopo aver ricevuto l'indirizzo, la vostra macchina risponde solo a pacchetti criptati con una data chiave. Conservate l' IP, siete in rete con chiunque abbia la vostra chiave, non lo siete per chiunque NON ce l'abbia. A costo praticamente nullo in termini di Opex.
Un altro paradigma che non regge col mondo dell' Internet of Things e' il modello client-server. Quando si parla di internet of things si parla sempre di "macchine che parlano tra loro" . Ma nessuno si e' mai chiesto cosa significhi "tra loro". Stiamo forse dicendo "macchine che parlano con un server e usano un server centrale per parlare tra loro?". No.
Stiamo dicendo "parlano tra loro". Se il vostro frigo, ll roomba , il robot che vi taglia l'erba, la lavastoviglie, il forno, la macchina per fare il pane, vogliono mettersi d'accordo tra loro per fare meno rumore possibile e non andare oltre i 3KWh (1), non devono per forza chiamare un server negli USA. Non fosse altro che per ragioni di performance e di opportunita', le macchine parlaranno con le macchine a loro vicine.
La vostra auto non ha nessun bisogno di chiedere ad un server statunitense di trovarle un parcheggio libero a Stoccarda: puo' interrogare altre auto chiedendo "avete spazio attorno a voi?", o puo' interrogare un centro di controllo cittadino: che senso ha andare sino negli USA?
Il concetto di M2M non e' una cosa tipo M2Cloud: nei dispositivi che si suppone entreranno nella Internet of Things c'e' troppa esigenza di real time e troppa necessita' di interazione LOCALE per poter garantire un mondo M2M centralizzato.
Una "Internet of Things" centralizzata e', sul piano architettonico, enormemente MENO performante rispetto ad una "Internet of Things" locale. Che cosa deve fare il vostro frigorifero, in definitiva? Anche avvisandovi che qualche cibo stia andando a male, o di essere vuoto, o di mandarvi la foto dell'interno, quanto lontani siete da un frigorifero DI CUI VI IMPORTI QUALCOSA? Se volete sapere cosa ci sia in frigo, siete nelle condizioni di interagire con lui. Parliamo di pochi KM.Quindi voi siete a Cinisello per lavorare, il vostro frigo e'a Famagosta: quale idiota vi farebbe comunicare gon gli USA, inserendo secondi di latenza, quando potete semplicemente andare direttamente da voi al frigo?
Se volete parlare con la vostra macchina del pane di casa e' perche' la mattina l'avete caricata, o perche' volete sapere se ha davvero fatto il pane - o se e' meglio che passiate da un fornaio . Non ha alcun senso passare per Google, se queste condizioni si verificano, siete a pochi KM di distanza.
Se volete controllare il vostro riscaldamento di casa non e' perche' siete a migliaia di KM di distanza:
Le persone passano nei pressi di casa la stragrande maggioranza del tempo. Immaginare una internet of things domestica SU SCALA GEOGRAFICA e' insensato sul piano dell'infrastruttura, assurdo sul piano dei costi, e non aggiunge alcun beneficio per l'utente.
la domotica e', per la stragrande maggioranza dei casi, un problema LOCALE.
Al vostro robot che annaffia il giardino non serve sapere che tempo faccia leggendo wetter.com: gli basta osservare il cielo.
Cosi', la "internet of things" ha bisogno di un DIVERSO paradigma rispetto al vecchio "client-server": ha bisogno di un paradigma P2P.
I robot che annaffiano il giardino sono piu' interessati a non accendere l'acqua tutti insieme, magari, per non far scendere di pressione il tubo della strada. I vostri elettrodomestici sono piu' interessati a comunicare tra loro per non far saltare i magnetotermici agendo tutti insieme che a leggere dati su Google. Il vostro orologio che chiama l'allarme , se non e' collegato in quel momento, puo' fare la cosa razionale di chiedere ad un altro dispositivo nei pressi di chiamare aiuto.
Internet of Things cambiera' moltissimo l'infrastruttura della rete. La cambiera' perche' la stragrande maggioranza dell'orchestrazione diventera' locale. Se vi chiedete con chi abbiano bisogno di fare M2M queste macchine, trovate entita' distanti pochi KM. CI saranno eccezioni come gli allarmi, ma non illudiamoci: frigoriferi, roomba, robot giardinieri, macchine per lapasta, forni a microonde, automobili , ascensori, non hanno bisogno di inviare messaggi sino negli USA.
Certo, magari all'inizio qualcuno sbattera' i vostri dati nel cloud e poi dira' alle altre macchine che vogliono parlarci di andarseli a prendere dal cloud. Ma quando l'ecosistema sara' completo, la "next big thing" sara' la possibilita' che tutte queste macchine parlino direttamente tra loro: le macchine che parlano solo con "vicini" saranno piu' veloci (per ovvie ragioni), piu' resistenti a problemi di rete, a problematiche legate all' ISP, e via dicendo.
Se consideriamo che nel mondo di "internet of things" parliamo di almeno 3-4 robots diversi a persona, piu' ammennicoli diversi, stiamo parlando di una rete ancora piu' grande di quella attuale, di un ordine di grandezza circa. Quindi, per realizzarla occorrera' letteralmente stravolgere la rete odierna, o almeno crearne un'altra, di un ordine di grandezza piu' capace.
In questi termini, cioe', tutti quelli che gridano "la internet of things sara' un incubo", dovrebbero smettere di pensare ad Internet come "grande rete globale" basata su IPv4, e a pensarla come bus locale basato su IPv6.
In questo scenario, pero', la mappa del potere cambia, e di molto, perche' si sposta verso governi ed autorita' locali. (il vostro comune/la vostra compagnia idrica potrebbe anche chiedere di accordarsi coi robot che annaffiano i giardini per limitare i consumi, per dire) . Chi immagina la dittatura dell' Internet of Things immagina la RETE DI OGGI con le macchine di domani.
Ma le macchine di domani avranno la rete di domani.
Quella che "misteriose forze" hanno fatto di tutto per ostacolare sinora. Sino a quando con Snowden, e' stato chiaro a tutti come mai IPv4 non sia gia' stato dato alle ortiche.
Rende la vita facile a qualcuno. IPv6 non e' invincibile di per se', ma irrobustire una rete e' molto MENO COSTOSO. L'idea stessa di "Spime", cioe' di usare un cloud centrale allo scopo di gestire realta' che per via della loro interazione FISICA sono locali, e' assurda sul piano dei costi e dell'architettura. ( http://en.wikipedia.org/wiki/Spime )
Volendo realizzare uno "Spime" come lo descrive Sterling, lo piazzerei nel router di casa piuttosto che a Mountain View (a meno di non vivere a Mountani View), per avere una possibilita' di interazione , miglior supporto, facilita' di riparazione, latenze inferiori, e persino privacy, tema che sta piano piano emergendo.
Quindi la cosa che dico e' molto semplice: e' inutile immaginare Spimes e Internet of Things con la rete DI OGGI. Per sostenere quella roba li', la rete deve cambiare radicalmente, come effettivamente cambiera', e nella rete di cui parliamo concetti come "server" o "cloud" sono del tutto ridicoli: parliamo di macchine materiali che interagiscono fisicamente a vostro vantaggio: sono per forza enti LOCALI. La prima costosissima qualita' che le reti di "Spime" o le "Internet of things" perderanno e' proprio la loro pervasivita', che e' costosa ed inutile, per cui economicamente insostenibile: arriverebbe sempre un altro vendor con il suo apparecchio che usa solo una piccola parte della rete locale, e vi taglierebbe fuori dal mercato coi suoi prezzi inferiori.
(1) Limite tipicamente italiano. Qui per esempio il limite e' la capacita' dell'impianto. Il mio scaldabagno rapido elettrico consuma 14KWh.