Conclusioni

CONCLUSIONI
pro & contro

pro

A partire da considerazioni già fatte è possibile sintetizzare i benefici derivanti dall' utilizzo dell' IPsec.

Confidenzialità, integrità e autenticità dei dati
I dati possono essere trasmessi attraverso una rete pubblica senza preoccuparsi di eventuali intrusioni o modifiche.
Soluzioni integrate
La sicurezza può essere implementata salvaguardando i costi, perchè non vi è la necessita di gestire una grossa rete aziendale autonoma ma è possibile ricavarne una virtuale dall' Internet già esistente.
Certificazione dei dispositivi
Questa qualità si ritrova soprattutto in reti di grandi dimensioni che necessitano di connessioni sicure tra molti dispositivi.
Flessibilità
Dati di tipo diverso possono essere cifrati utilizzando chiavi e algoritmi differenti; cioè il protocollo è indipendente dal particolare algoritmo di crittografia usato.

contro

   Dopo un tanto parlare di IPSec e dei suoi benefici diamo ora spazio a una rivisitazione critica del protocollo. Non avendo le conoscenze sufficienti per una nostra autonoma critica ci si
è riferiti ad un illuminante articolo dal titolo " A Cryptographic Evaluation of IPsec " degli
autori Niels Ferguson e Bruce Schneier dipendenti della Counterpane Internet Security Inc.
Il testo scritto nel febbraio del 1999 si accanisce su pressochè tutti gli aspetti protocollari. Di seguito rielaboreremo quanto letto soffermandoci sui passaggi salienti.

   A chi addebitare il fallimento in sicurezza di IPSec?Ai comitati di standardizzazione che lo hanno appesantito eccessivamente.Infatti come si è realmente visto esso contiene troppe opzioni e troppa flessibilità, effetto diretto dei comitati.
Tranello della complessità
La complessità risulta essere il peggiore nemico della sicurezza, perchè un sistema complesso fornisce più punti deboli, che sono al tempo stesso difficili da scovare per essere migliorati.
In particolare il test di un sistema di sicurezza è un processo manuale che richiede tempo,che cresce sempre più, quanto maggiori sono le possibilità da testare. Quale il rimedio? Una buona modularizzazione può ridurre notevolmente la complessità senza dover rinunciare a delle
opzioni. IPSec risulta troppo complesso per poter essere "veramente" sicuro.
Documentazione poco chiara
La documentazione fruibile ( Internet Draft, RFC) è troppo complessa. In particolare ci si riferisce alle specifiche dell' ISAKMP. Dal canto nostro possiamo confermare questa accusa.
Spesso gli standard non si prefiggono degli obiettivi.
Bisogna eliminare la modalità transport mode
L' IPSec ha 2 modalità operative: tunnel mode e transport mode ; sia l' AH che l' ESP le implementano. La funzionalità del tunnel mode sembra essere una funzionalità aggiunta del
transport mode. L'unico vantaggio che ne deriva è il ridotto overhead introdotto rispetto alla restante possibilità. Seguendo sempre la via prima tracciata, eliminare il transport mode significa guadagnare in semplicità ovvero in sicurezza.
Bisogna eliminare il protocollo AH
Si ricorderà che il protocollo AH autentica gli headers IP dei livelli più bassi, con una chiara violazione del pricipio di modularità architetturale. Si può utilizzare l' authentication dell' ESP in tunnel mode.Si avrà un aumento di overhead, cioè uno spreco di banda, che potrebbe essere eliminato con un algoritmo di compressione ad hoc.
Modificare l'ESP per fornire sempre autenticazione
L' ESP permette di criptare i dati senza autenticarli è ciò risulta inutile nella maggior parte delle applicazioni reali. E' bene che l'ESP fornisca sempre autenticazione.
Invertire l'ordine delle operazioni
Al momento, prima si cripta e solo dopo si autentica, mentre sarebbe opportuno invertire questo ordine: autenticare il testo in chiaro o "plaintext" e dopo criptare ottenedo il testo criptato o "chipertext".
Note:

il protocollo AH risulta soggetto all' attacco di risposta (replay attack).

E' bene scartare subito il testo che non può essere autenticato in modo da eliminare il sovraccarico computazionale dovuto al decriptare messaggi che poi dovranno essere comunque scartati.

SA dovrebbe essere bidirezionale
La Security Association fornisce un canale sicuro in una sola direzione e addirittura utilizzando 2 protocolli per lo stesso pacchetto bisogna avere 2 SA. Del resto nelle applicazioni reali è veramente straordinario che solo il traffico in un verso abbia bisogno di sicurezza.
Ovvia conseguenza : rendere l'SA bidirezionale.
Note:

Bisogna ridurre al minimo l' informazione che può essere soggetta ad attacchi.

Il routing non risulta così efficiente come era stato detto, perchè la descrizione della gestione degli ICMP è poco chiara. Cosa potrebbbe accadere? I routers, non essendo a conoscenza degli SA tra 2 end-users, spediranno indietro un messaggio ICMP qualora un pacchetto che appartiene alla SA venga perso, tuttavia quest'ultimo verrà scartato in quanto non potrà essere autenticato dalla sorgente.

La raccomandazione vuole che il DES in CBC mode venga supportato da tutte le implementazioni ma questo algoritmo non risulta sicuro (lunghezza delle chiavi limitata) e dovrebbe essere sostituito dal triple DES.

ISAKMP e IKE
L' ISAKMP che stabilisce l'SA e fornisce ulteriori funzioni di gestione delle chiavi è descritto in maniera confusa. L' IKE è il protocollo standard per lo scambio delle chiavi per ISAKMP e gestisce la negoziazione di alcuni importanti parametri come la funzione hash e la funzione pseudorandom (PRF).Questo protocollo non è completamente sicuro.

     Tirando le somme Ferguson e Schneier affermano:

L' IPSec ha seri problemi di sicurezza per buona parte derivanti dalla sua complessità,dovuta a sua volta alla presenza dei comitati di standardizzazione che hanno voluto il protocollo troppo flessibile.

L' IPSec risulta comunque al momento il migliore protocollo di sicurezza presente sul mercato e ne viene raccomandato l'uso.