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 potrebbe essere effettuata su base 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 respingere attacchi di intercettazione attiva contro le connessioni TCP inter-router. In assenza dell'uso di meccanismi che realizzano questi servizi di sicurezza, gli aggressori possono interrompere queste connessioni TCP e/o mascherarsi da router peer legittimo. Poiché il meccanismo definito nella RFC non fornisce autenticazione dell'entità peer, queste connessioni possono essere soggette ad alcune forme di attacchi replay che non verranno rilevati a livello TCP. Tali attacchi potrebbero portare alla consegna (da TCP) di messaggi BGP "rotti" o "falsificati".

Il meccanismo definito in RFC 2385 aumenta il normale checksum TCP con un codice di autenticazione del messaggio (MAC) di 16 byte che viene calcolato sugli stessi dati del 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 ed è utilizzata per generare valori MAC che non sono facilmente calcolabili da un aggressore che non ha accesso alla chiave. Un'implementazione conforme deve (MUST) supportare questo meccanismo e deve (MUST) consentire a un amministratore di rete di attivarlo su base per peer.

RFC 2385 non specifica un mezzo di gestione (ad esempio, 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 motivazioni per supportare queste indicazioni. Si nota che una chiave distinta dovrebbe essere utilizzata per la comunicazione con ciascun peer protetto. Se la stessa chiave viene utilizzata per più peer, i servizi di sicurezza offerti possono essere degradati, ad esempio a causa di un maggiore rischio di compromissione su un router che influisce negativamente su altri router.

Le chiavi utilizzate per il calcolo MAC dovrebbero essere cambiate periodicamente, per minimizzare l'impatto di una compromissione della chiave o di un attacco crittoanalitic riuscito. RFC 3562 suggerisce un periodo crittografico (l'intervallo durante il quale viene impiegata una chiave) di, al massimo, 90 giorni. Cambiamenti di chiave più frequenti riducono la probabilità che gli 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 questa RFC supporteranno cambiamenti di chiave frequenti.

Ovviamente, ogni chiave dovrebbe anche essere scelta in modo da essere difficile da indovinare per un aggressore. 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 alle implementazioni di supportare 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 all'estremità 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].