Protocollo OSPF
Il protocollo di routing OSPF si fonda invece su un algoritmo noto come Link State.
In accordo a questo schema, ogni router è responsabile di consegnare indicazioni sullo stato dei collegamenti per le reti direttamente connesse a tutti gli altri nodi.
Per consentire l’inoltro degli annunci OSPF a tutti i router della rete, senza poter contare su una tabella di routing precostituita, i progettisti del protocollo hanno scelto di adottare il meccanismo di inoltro denominato flooding.
Questo meccanismo stabilisce che ogni router deve fare da relay dei messaggi OSPF ricevuti dagli altri router.
Mantenendo un database dei messaggi recentemente ricevuti e trasmessi è possibile evitare l’inutile propagazione di messaggi OSPF sulla rete.
Al ricevimento di un annuncio, ciascun router utilizza le informazioni contenute nel messaggio, per costruire e/o modificare la propria mappa della rete (tramite l’algoritmo di Dijkstra) e conseguentemente la propria tabella di routing.
Per limitare il numero di annunci, l’OSPF prevede che la rete sia suddivisa in aree.
Un generico router che partecipa all’OSPF si deve preoccupare solo di comunicare con gli altri router appartenenti alla stessa area, lasciando il compito delle comunicazioni inter-area a particolari router di frontiera OSPF.
Per evitare che il meccanismo di flooding, su reti che supportano il broadcast fisico (esempio Ethernet) risulti poco affidabile, è inoltre previsto che, tra tutti i router OSPF direttamente connessi allo stesso segmento di rete locale, sia eletto un OSPF Designated Router (OSPF-DR).
Il ruolo del OSPF-DR è quello di ricevere gli annunci da ciascun router direttamente connesso e rifletterli agli altri router.
La comunicazione con il OSPF-DR avviene tramite pacchetti IP con indirizzo destinazione riservato multicast 224.0.0.6.; la riflessione degli annunci avviene invece specificando l’indirizzo riservato multicast 224.0.0.5.
L’indirizzo IP sorgente non è invece univocamente determinato (in certi router coincide con l’indirizzo della propria interfaccia interna di loopback, in altri dispositivi può essere settato a valori diversi).
Il protocollo OSPF si compone di tre distinte procedure.
- Hello Protocol, responsabile di testare lo stato dei collegamenti con i router vicini.
- Exchange Protocol, responsabile di scambiare le informazioni acquisite con il protocollo Hello.
- Flooding Protocol, responsabile di diffondere le informazioni riguardanti le modifiche dello stato dei collegamenti quando queste avvengono.
Per ogni procedura il protocollo OSPF prevede messaggi strutturalmente diversi. Il protocollo Hello prevede un solo tipo di messaggio (denominato tipo = 1);
il protocollo Exchange prevede due diversi tipi di messaggi, (tipo = 2, per la descrizione della base dati e tipo = 3, per le richieste di sincronizzazione delle informazionicontenute nella base dati);
lo stesso vale per il protocollo Flooding (tipo = 4, per l’aggiornamento dello stato dei collegamenti e tipo = 5, per il riscontro degli aggiornamenti).
Tutti i messaggi OSPF sono trasportati direttamente entro datagrammi IP (Protocol Type = 89).
Per la natura del servizio di consegna dei datagrammi IP (non è prevista connessione), è naturale che il protocollo OSPF preveda che ogni messaggio sia indipendentemente autenticato.
Nonostante la diversa funzione delle componenti che costituiscono l’OSPF, tutti i messaggi OSPF presentano una comune intestazione.
All’interno di questa intestazione è presente un campo per il trasporto di dati utili per l’autenticazione.
A parte la maggiore complessità del protocollo OSPF, la politica di sicurezza è formalmente identica a quella adottata dal protocollo RIP.
Per limitare la diffusione degli annunci OSPF è possibile configurare come passive, specifiche interfacce del router.
È inoltre possibile attivare una procedura di autenticazione per validare i messaggi OSPF ricevuti prima che questi vengano processati.
Il protocollo OSPF originalmente prevedeva solo 8 byte per trasportare i dati per l’autenticazione della sorgente.
Le implementazioni successive del protocollo prevedono la possibilità di autenticare la fonte dei messaggi sia tramite uso di una password predefinita, trasmessa in chiaro nell’intestazione del messaggio, sia tramite utilizzo di funzioni di digest.
Nel primo caso il risultato è suscettibile a replay attack.
Nel secondo caso la password condivisa viene appesa al messaggio e processata attraverso un digest MD5 (il solo algoritmo definito dallo standard, rfc 2328).
In tal caso il risultato della funzione digest viene appeso al messaggio e non viene considerato parte del messaggio OSPF.
Utilizzando funzioni di digest, ogni codice inserito nell’intestazione è valido esclusivamente per il singolo messaggio trasmesso.
Un attaccante può eventualmente solo riproporre messaggi già trasmessi , anche se è mutato lo stato di un link.
Per evitare che un hacker possa riproporre nel breve periodo un messaggio legittimo precedente, anche OSPF utilizza numeri sequenziali crescenti a 32 bit.
La principale limitazione della soluzione digest resta comunque l’uso di un segreto che non cambia nel tempo (password statica) e del solo algoritmo MD5 quale funzione di hash.
Un attaccante può individuare per tentativi la password statica (tramite brute force attack per esempio) o utilizzando forme di crittoanalisi legate a MD5 come l’uso di rainbow table.
Una volta scoperta la password, l’hacker può iniettare qualsiasi messaggio OSPF nella rete.
