news

Internet Protocol Journal -Luglio 2017

Nel numero IPJ di Luglio 2017 si parla dei processi automatici per il rilascio dei certificati digitali web e dei server root nel sistema DNS.

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.

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.

 

Internet Protocol Journal -Marzo 2017

Il numero IPJ di Marzo 2017 espone 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.

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.

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 ?

Nell'ultimo articolo Geoff Huston e Luis Silva Dama 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.