28.5.1 Sicurezza e robustezza di BGP
BGP appartiene alla classe dei protocolli di path vector routing, in cui ogni nodo pubblicizza il percorso “migliore” per ogni destinazione a tutti i suoi vicini. Un nodo BGP memorizza tutti i percorsi inviati dai suoi vicini, ma usa e pubblicizza solo quello che è “migliore” secondo una certa politica. Quando questo percorso primario fallisce, BGP ritira questo percorso e seleziona il prossimo miglior percorso di backup. Il nuovo percorso viene poi pubblicizzato ai suoi vicini.
La ragione fondamentale della popolarità di BGP è la sua grande flessibilità nell’impostare e utilizzare i percorsi, in modo che ogni Internet Service Provider (ISP) possa implementare le sue politiche desiderate senza doverle rendere pubbliche. Sfortunatamente, questa flessibilità e opacità sono anche la causa di molti problemi con BGP, tra cui configurazioni incompatibili da parte di diversi ISP, mancanza di visibilità globale sulla qualità o sullo stato dei percorsi, e incapacità di montare un approccio coordinato per gestire i problemi di routing. Per esempio, anche se tutti i percorsi sono scelti rigorosamente basati sulle stime dei costi, BGP spesso mostra un comportamento indesiderato come lunghi ritardi di convergenza e oscillazioni perché le informazioni sulla disponibilità del percorso sono tipicamente dedotte piuttosto che propagate esplicitamente. Come risultato, BGP può sostituire un percorso fallito con il successivo migliore senza rendersi conto che la sua valutazione locale di questo percorso è errata. Questa assenza di informazioni sulla validità di un percorso può far sì che BGP passi attraverso un certo numero di percorsi di backup prima di selezionarne uno valido. Il ciclo di ritiri/annullamenti può continuare per un tempo considerevole. Questo ritardo è noto come ritardo di convergenza (o tempo di recupero). Queste vulnerabilità possono anche essere sfruttate da un aggressore per far sì che BGP si comporti in modo peggiore del solito.
Il problema della convergenza è stato ampiamente esaminato in letteratura. In particolare, è stato dimostrato da Labovitz et al. che il ritardo di convergenza per i ritiri isolati delle rotte può essere maggiore di tre minuti nel 30% dei casi e potrebbe arrivare a 15 minuti. Hanno anche scoperto che il tasso di perdita dei pacchetti può aumentare di 30x e il ritardo dei pacchetti di 4x durante il recupero. Ci sono anche molti tentativi di migliorare il ritardo di convergenza BGP attraverso una varietà di tecniche. Reference esamina la questione delle prestazioni di consegna dei pacchetti e propone una tecnica per ridurre la perdita di pacchetti e il ritardo.
Esaminiamo ora la robustezza delle tabelle di routing stesse. Sebbene sia difficile corrompere le tabelle di routing direttamente, i legittimi messaggi di aggiornamento della tabella di routing potrebbero essere dirottati per creare tabelle di routing incoerenti. In alternativa, messaggi di aggiornamento fasulli potrebbero essere inviati semplicemente per esaurire le risorse di calcolo, di memoria o altre risorse dei router. Un problema correlato è quello della perturbazione delle impostazioni QoS, che possono essere sfruttate per interrompere il corretto trattamento del traffico. La soppressione, la duplicazione o la modifica dei messaggi di aggiornamento del percorso possono causare una cattiva consegna e una congestione. Tali attacchi sono stati ampiamente considerati in letteratura, e la protezione avviene tramite mezzi crittografici come l’autenticazione dei messaggi di aggiornamento e la crittografia del contenuto dei pacchetti o delle intestazioni. Reference fornisce una panoramica completa delle vulnerabilità BGP e dei numerosi meccanismi di protezione.
Secure BGP (SBGP) utilizza aggiornamenti di rotta firmati facendo uso di due gerarchie PKI, una per garantire l’integrità dei prefissi IP e l’altra per i numeri AS. L’obiettivo principale di SBGP è quello di garantire l’integrità del “AS-path” registrato negli aggiornamenti di rotta e i prefissi IP pubblicizzati. (AS-path è l’elenco degli AS attraverso i quali un messaggio di annuncio o ritiro di rotta BGP viaggia prima di raggiungere la sua destinazione). L’uso della gerarchia PKI è essenziale per avere una catena di fiducia per ogni prefisso IP e AS-path; tuttavia, la necessità di più operazioni a chiave pubblica rende lo schema piuttosto lento. Hu, Perrig e Johnson discutono un meccanismo veloce per assicurare gli aggiornamenti di routing per BGP. Gli autori sostengono l’uso della crittografia simmetrica, che è molto più efficiente dell’uso della PKI. Essi sostengono l’uso di catene di hash che coinvolgono un codice di autenticazione del messaggio (MAC) in ogni nodo lungo il percorso preso dai pacchetti di aggiornamento per garantire che gli aggiornamenti non siano manomessi e i nodi siano aggiunti o rimossi dal percorso. Anche se un tale schema può rendere sicuri gli aggiornamenti, ci sono ancora problemi di scambio di chiavi e l’overhead del controllo dei MAC attraverso le catene di hash. L’Inter-domain Route Validation (IRV) è un’autenticazione molto diversa in cui un server IRV in ogni AS può opzionalmente convalidare l’aggiornamento dall’originatore dell’AS.
Anche se le tecniche crittografiche sono in grado di assicurare gli aggiornamenti di routing contro i cambiamenti non autorizzati, esse portano complessità extra e quindi aumentano le possibilità di configurazioni errate. Infatti, i problemi di SBGP, che usa una gerarchia PKI, sono simili ai problemi DNSSEC discussi nella sezione 28.3.3.
In rari casi, un AS può diventare esso stesso maligno, forse a causa della compromissione da parte di un avversario. Per esempio, un AS BGP malevolo può decidere di non ritirare una rotta non funzionante o non riuscire a mettere una rotta funzionante nell’insieme delle rotte correnti. Un AS malevolo potrebbe anche pubblicizzare falsamente di avere il percorso più desiderabile (ad esempio, il più breve) verso una certa destinazione. Questo farà sì che tutto il traffico verso la destinazione sia instradato attraverso questo AS e l’AS potrebbe o spiare il traffico o semplicemente scartarne una parte o tutto e causare un denial of service. La modifica dell’AS-path può anche causare impatti simili. Raggiungere un routing robusto a dispetto di alcuni AS malevoli può essere molto difficile, ma può essere sufficiente rilevare e mettere in quarantena tali AS.