Next: 4 Il protocollo HIP Up: 5 L'instaurazione della connessione Previous: 2 Handshake in sistemi Indice Indice analitico
L'algoritmo è descritto in dettaglio in [26], comunque il funzionamento in linea generale è il seguente:
La opportunistic encryption non è implementata nella versione 1.9 di FreeS/WAN, ed è stata inclusa solo a partire dalla versione 1.91 (giugno 2001): per le prove di laboratorio che sono state condotte per verificarne le funzionalità si sono utilizzati alcuni snapshot sperimentali di sviluppo successivi alla release 1.9 (per le misurazioni sull'handshake, che verrano illustrate nel capitolo 6, si è utilizzata la versione 1.91). Si sono utilizzate solamente due macchine (quindi in un'ottica end-to-end e non gateway-to-gateway), installando su una di esse anche un server DNS; le macchine sono state lasciate collegate alla rete locale per vedere l'effetto di altro traffico in entrata e uscita.
Un problema evidenziato è il seguente: con la opportunistic encryption il sistema intercetta ogni pacchetto in uscita e invoca il demone IKE per cercare di instaurare una connessione IPsec. Per questo deve però interrogare il server DNS, e quindi generare altri pacchetti in uscita, i quali vengono intercettati e così via. Il problema è risolvibile ad esempio installando manualmente una route in chiaro verso il server DNS44, oppure inserendo una regola che esclude dall'elaborazione IPsec il traffico DNS45 (per autenticare le risposte del DNS si usa DNSSEC46, mentre la riservatezza in questo caso potrebbe non essere importante).
Un altro problema riscontrato durante i test è questo: quando un pacchetto viene intercettato, si installa una regola di tipo ``hold'' per la destinazione, il che significa che il pacchetto viene tenuto in attesa finché la negoziazione opportunistic non è terminata (con esito positivo o negativo), mentre in caso di arrivo di altri pacchetti per la stessa destinazione viene tenuto in attesa soltanto il più recente, scartando i pacchetti precedenti. Si è visto però che in condizioni di alto carico è possibile che non si ottenga risposta dal DNS, il che comporta che la regola di ``hold'' rimane al suo posto bloccando qualsiasi comunicazione con la destinazione. Il problema è stato segnalato al team di sviluppo di FreeS/WAN, ed è stato risolto inserendo un timeout associato a tali regole.
Quello che appare probabilmente il problema maggiore di questo approccio è comunque legato agli attacchi di denial of service: è infatti sufficiente inviare ad un gateway con opportunistic encryption dei pacchetti ICMP echo request (ovvero dei ping) con indirizzi mittente fasulli per costringere il gateway ad una query DNS sincrona per ognuno di questi indirizzi, e ad iniziare degli handshake IKE (con tutto il carico computazionale che comportano) nel caso da tali interrogazioni si ottengano le informazioni sufficienti per farlo. Questo rischio è notevole, anche in considerazione del fatto che ci si occupa di protocolli di sicurezza, e purtroppo il problema non sembra di facile soluzione a meno di cambiare profondamente i protocolli che entrano in gioco.
Dal punto di vista della definizione del protocollo, il formato dei pacchetti di IKE e la struttura dell'handshake non vengono intaccati. L'impatto di questa proposta, più che sulla definizione di IKE, ricade sulla sua implementazione: un demone IKE ``opportunistic'' deve infatti essere in grado di gestire le interrogazioni e le risposte DNS coinvolte nel processo (con i record KEY e TXT) e deve essere pronto a negoziare security association con qualunque altra macchina (il che può comportare grandi necessità di risorse per mantenere gli stati associati alle connessioni e grandi necessità di entropia per generare dati casuali quali i nonce). Per quanto riguarda quest'ultimo aspetto, che può rientrare anch'esso negli svantaggi di questo approccio dal punto di vista del denial of service, si vedrà nel prossimo paragrafo che il protocollo HIP è invece pensato con una maggiore attenzione in proposito.