2017 |
 |
TECHNICAL FOCUS
La pubblicazione tecnica di IPJ [Fall2017 issue]
I focus di questo numero: il blockchain come introduzione al bitcoin e la rivalutazione del Network Address Traslation (NAT).
BLOCKCHAIN
Il primo articolo a cura di William Stallings è una sorta di tutorial sul blockchain, una nuova tecnologia che ha aperto la strada alla sua applicazione più famosa, ossia il Bitcoin.
Un blockchain può essere definito come una sequenza lineare di blocchi usati per memorizzare transazioni in modo cifrato. Ogni blocco contiene una o più transazioni relazionate tra loro, e i blocchi sono ordinati in sequenza temporale. Perciò ogni blocco rappresenta un insieme di eventi che sono accaduti in un determinato intervallo di tempo che è consequenziale ad un procedente blocco nella catena e precedente al blocco che segue nella catena. Gli utenti che accedono alla catena possono leggere ogni transazione nella sequenza e aggiungere un nuovo blocco alla fine di questa. Il termine “blockchian” è usato anche per descrivere il network di nodi o dei registri digitale distribuiti dove queste transazioni sono memorizzate.
L’applicazione più importante che utilizza questa tecnologia è il “Bitcoin”.
Il “Bitcoin” è una criptovaluta, chiamata còsì perchè la crittografia è l’operazione fondamentale del blockchian, ed è la valuta alternativa più usata al mondo. Più in dettaglio, è uno schema di moneta digitale, che viene creata dal network di computers facenti funzione di “miners”, ognuno dei quali mette a disposizione del network la propria potenza di calcolo. Il valore dei bitcoim è dato dalla sua scarsità: questa scarsità viene creata richiedendo che tale moneta sia processata da procedure computazionali intensive. In breve, tanto più il miner mette a disposizione la sua potenza di calcolo tanto più velocemente crea valore a Bitcoin. A differenza della valute tradizionali il valore di Bitcoin è determinato dalla leva di domanda e offerta, e non può essere controllato data la natura distribuita del metodo di creazione della moneta . Inoltre, non soffre di inflazione in quanto la quantità di moneta in circolazione è conosciuta a priori ed è prevedibile dai suoi utilizzatori anche in futuro.
NAT
Nel successivo articolo Geoff Huston (APNIC) prende le difese del NAT, nota tecnica che permette l’utilizzo di connessioni Internet di un endpoint attraverso l’uso di un unico indirizzo IP abbinato ad un determinato numero di porta TCP. Nato come soluzione temporanea nei primi anni ’90 per permettere al successore del protocollo IPv4, ossia IPv6, di venire utilizzato sempre più per necessità dettata dal consumo degli indirizzi IP pubblici vincolati ai registri di 32 bits di IPv4, è tutt’ora usato massivamente. Ma non solo.
Di fatto ha rallentato il deployment di IPv6, ma sopratutto ha contribuito con uno step positivo nell’evoluzione di Internet spostando il focus non più sull’importanza dell’unicità degli indirizzi IP (in relazione 1:1) nei canali comunicativi end-to-end ma sui nomi delle applicazioni o servizi, named content, che l’utente richiede, verso una nuova architettura chiamata Name Data Networking (NDN).
La pubblicazione tecnica di IPJ [Summer2017 issue]
I focus di questo numero parlano dei processi automatici per il rilascio dei certificati digitali web e dei server root nel sistema DNS.
AUTOMATIC CERTIFICATE MANAGEMENT ENVIRONMENT
Nel primo articolo di Daniel McCarney si presenta una panoramica sul Automatic Certificate Management Environment (ACME), un protocollo nato dallo sforzo di alcune realtà organizzative riunite nel gruppo di lavoro IETF ora chiamato Last Call. Questo protocollo, ancora in fase di sviluppo, si occupa del processo per automatizzare i metodi usati dagli enti certificatori CA, come Let’s Encrypt, per validare domini web, che in tal modo risultano sicuri attraverso l’uso di un ceritificato che cifra il canale comunicativo con esso.
ROOT DNS
Il successivo articolo (Geoff Huston, APNIC) analizza uno degli elementi essenziali di un servizio basico quale il DNS: i root servers system. Questi sono dei server che rispondono in prima o sequenziale istanza alle queries dei name-server resolver o caching DNS, quelli poi utilizzati dagli utenti finali. Nel corso degli anni il servizio DNS si è evoluto per “merito” del grave problema della insicurezza e pericolosità che questo porta con se, ed è nato DNSSEC (DNS Security). Questo conduce a delle riflessioni sul futuro lavoro che coinvolge l’intera comunità per studiare, ottimizzare e rendere sempre più robusta l’infrastruttura di un sistema quale il Domain Name System sotto la crescente pressione di Internet.
La pubblicazione tecnica di IPJ [Spring2017 issue]
I focus di questo numero: le nuove specifiche Large Communities per BGP, i rischi per la sicurezza che portano le periferiche IoT ed infine la disamina sulla privacy da difendere nelle transazioni DNS.
BGP
Nel primo articolo Job Snijders descrive la sua esperienza personale in un gruppo ristretto all’interno del IETF ((Internet Engineering Task Force) nello sviluppo delle specifiche chiamate Large Communities per il protocollo BGP. Ricordiamo che il protocollo BGP è il protocollo di routing usato degli operatori Internet providers facenti parte ad un Autonomous System.
Le BGP Communities sono delle meta-informazioni aggiuntive alle rotte di instradamento presenti nelle tabelle. Le nuove Large Communities rispondono alle nuove esigenze di fornire ed ottenere più informazioni codificate attraverso un nuovo registro di 96 bits.
INSECURE-IOT
Nel secondo articolo Bob Hinden illustra il problema della sicurezza che porta il diffondersi dei devices IoT, Internet of Things.
I firmware poco aggiornati, uniti alla poca consapevolezza degli end-users sul rischio di una mancata modifica delle credenziali di default per la loro configurazione, ha fatto si che questi apparecchi (es. le videocamere IP a scopo domestico) stiano diventando bersaglio prediletto di attackers che utilizzano dei malware appositi per introdursi in questi sistemi e pilotarli, ad insaputa degli utilizzatori finali, contro target importanti con attacchi classici come DDoS (Distributed Denial Of Service) con picchi di terabit di dati traffico per secondo.
Che fare, dunque ? Quali sono le migliori strategie per difendersi da questo scenario ?
DNS-PRIVACY
Nell’ultimo articolo Geoff Huston e Luis Silva Damas affrontano il delicato tema della riservatezza delle informazioni che le sessioni DNS portano con se. La catena che veicola l’informazione IP richiesta consta, infatti, di numerosi passaggi dal client al DNS resolver, da questi al DNS root server e finalmente la richiesta viene inoltrata all’authoritative name server per la risoluzione finale dell’indirizzo IP richiesto per il nome specifico.
Il rischio che esterni riescano ad individuare e manipolare queste informazioni che transitano in chiaro è reale e, come intuibile, molto pericoloso. Da questo è nato di recente il protocollo DNSSEC (Domain Name System Security Extensions) per rendere tutte queste transazioni cifrate e sicure.
L’uso di DNSSEC non è, però, molto comune tra i sistemi ed ecco che IETF ha attivato al suo interno un “Working Group” specifico chiamato DNS PRIVate Exchange (DPRIVE) per studiare una soluzione efficace che sappia assicurare che la risposta alla richiesta del client arrivi dal resolver a cui era stata fatta, e che, secondariamente, tale richiesta venga letta esclusivamente dal resolver stesso.
Nascono così due nuovi protocollo d’approccio, alternativi uno all’altro: il DNS-over-TLS-over-TCP ed il DNS-over-DTLS (Datagram Transport Layer Security), adattamento, quest’ultimo, delle funzioni del TLS al protocollo di trasposto Datagram usato per le normali sessioni DNS e più efficace rispetto al TCP.