Security Considerations (Considerazioni sulla sicurezza)
Security Considerations (Considerazioni sulla sicurezza)
Un'implementazione BGP DEVE (MUST) supportare il meccanismo di autenticazione specificato in RFC 2385 [RFC2385]. L'autenticazione fornita da questo meccanismo può essere effettuata per peer.
BGP utilizza TCP per il trasporto affidabile del suo traffico tra router peer. Per fornire integrità orientata alla connessione e autenticazione dell'origine dei dati su base punto-punto, BGP specifica l'uso del meccanismo definito in RFC 2385. Questi servizi sono destinati a rilevare e rifiutare attacchi di intercettazione attiva contro le connessioni TCP inter-router. In assenza dell'uso di meccanismi che effettuano questi servizi di sicurezza, gli attaccanti possono interrompere queste connessioni TCP e/o mascherarsi come router peer legittimo. Poiché il meccanismo definito nell'RFC non fornisce autenticazione dell'entità peer, queste connessioni possono essere soggette ad alcune forme di attacchi replay che non saranno rilevate a livello TCP. Tali attacchi potrebbero comportare la consegna (da TCP) di messaggi BGP "rotti" o "falsificati".
Il meccanismo definito in RFC 2385 aumenta la normale checksum TCP con un codice di autenticazione del messaggio (MAC) di 16 byte che viene calcolato sugli stessi dati della checksum TCP. Questo MAC si basa su una funzione hash unidirezionale (MD5) e sull'uso di una chiave segreta. La chiave è condivisa tra router peer e viene utilizzata per generare valori MAC che non sono facilmente calcolabili da un attaccante che non ha accesso alla chiave. Un'implementazione conforme deve supportare questo meccanismo e deve consentire a un amministratore di rete di attivarlo per peer.
RFC 2385 non specifica un mezzo per la gestione (ad es. generazione, distribuzione e sostituzione) delle chiavi utilizzate per calcolare il MAC. RFC 3562 [RFC3562] (un documento informativo) fornisce alcune indicazioni in quest'area e fornisce una motivazione per supportare questa guida. Si nota che una chiave distinta dovrebbe essere utilizzata per la comunicazione con ogni peer protetto. Se la stessa chiave viene utilizzata per più peer, i servizi di sicurezza offerti potrebbero essere degradati, ad es. a causa di un aumento del rischio di compromissione su un router che influisce negativamente su altri router.
Le chiavi utilizzate per il calcolo del MAC dovrebbero essere cambiate periodicamente, per minimizzare l'impatto di una compromissione della chiave o di un attacco crittanalitico riuscito. RFC 3562 suggerisce un periodo crittografico (l'intervallo durante il quale una chiave viene impiegata) di al massimo 90 giorni. Cambi di chiave più frequenti riducono la probabilità che attacchi replay (come descritto sopra) siano fattibili. Tuttavia, in assenza di un meccanismo standard per effettuare tali cambiamenti in modo coordinato tra peer, non si può presumere che le implementazioni BGP-4 conformi a questo RFC supporteranno cambi di chiave frequenti.
Ovviamente, ogni chiave dovrebbe anche essere scelta in modo da essere difficile da indovinare per un attaccante. Le tecniche specificate in RFC 1750 per la generazione di numeri casuali forniscono una guida per la generazione di valori che potrebbero essere utilizzati come chiavi. RFC 2385 richiede che le implementazioni supportino chiavi "composte da una stringa di ASCII stampabile di 80 byte o meno". RFC 3562 suggerisce che le chiavi utilizzate in questo contesto siano da 12 a 24 byte di bit casuali (pseudo-casuali). Questo è abbastanza coerente con i suggerimenti per algoritmi MAC analoghi, che tipicamente impiegano chiavi nell'intervallo da 16 a 20 byte. Per fornire abbastanza bit casuali al limite inferiore di questo intervallo, RFC 3562 osserva anche che una tipica stringa di testo ASCII dovrebbe essere vicina al limite superiore per la lunghezza della chiave specificata in RFC 2385.
L'analisi delle vulnerabilità BGP è discussa in [RFC4272].