13. Considerazioni sulla sicurezza

13. Considerazioni sulla sicurezza (Security Considerations)

13.1. Data Plane (Data Plane)

Per "sicurezza nel data plane" (data plane) intendiamo la protezione contro le seguenti possibilità:

• Pacchetti (packet) provenienti dall'interno di un VPN raggiungano un sito esterno a quel VPN, in modo non conforme alla politica (policy) di quel VPN.

• Pacchetti provenienti dall'esterno di un VPN penetrino in un sito di quel VPN, in modo non conforme alla politica di quel VPN.

Alle seguenti condizioni:

1. un router di backbone (backbone router) non accetta un pacchetto etichettato su un particolare collegamento dati (data link), a meno che non sia stabilito che tale collegamento dati è collegato solo a sistemi fidati (trusted), o a meno che non sia stabilito che tali pacchetti lasciano il backbone prima che l'header IP (IP header) o qualsiasi etichetta più in basso nello stack sia esaminata, e

2. le route VPN-IPv4 con etichetta non siano accettate da peer di instradamento (routing peer) non fidati o non affidabili,

3. non sia stato condotto alcun attacco (attack) riuscito sul control plane (control plane),

la sicurezza del data plane fornita da questa architettura è essenzialmente la stessa offerta ai VPN dai backbone Frame Relay o ATM. Se i dispositivi sotto il controllo del SP sono configurati correttamente, i dati non entrano né escono da un VPN se non dove autorizzati.

La condizione 1 sopra può essere enunciata più precisamente. Un pacchetto etichettato ricevuto da un particolare vicino (neighbor) dovrebbe essere scartato (discard) a meno che una delle due seguenti condizioni non sia soddisfatta:

• l'etichetta in cima (top label) del pacchetto ha un valore di etichetta che il sistema ricevente ha distribuito a quel vicino, oppure

• l'etichetta in cima del pacchetto ha un valore di etichetta che il sistema ricevente ha distribuito a un sistema oltre quel vicino (cioè quando è stabilito che il percorso dal sistema a cui l'etichetta è stata distribuita al sistema ricevente può passare per quel vicino).

La condizione 2 è di massima importanza nel caso dei VPN tra più fornitori (vedere sezione 10). Per i VPN tra più fornitori costruiti secondo lo schema b) della sezione 10, la condizione 2 è facile da verificare. (La questione della sicurezza quando si usa lo schema c) della sezione 10 è lasciata a ulteriori studi.)

È degno di nota che l'uso di MPLS rende molto più semplice fornire la sicurezza del data plane che se si tentasse di usare una forma di tunnel IP al posto dell'etichetta esterna MPLS. È semplice fare in modo che un router di confine rifiuti di accettare un pacchetto etichettato, a meno che la prima delle condizioni sopra non si applichi. È invece piuttosto difficile configurare un router per rifiutare di accettare un pacchetto tunnelizzato IP il cui indirizzo di destinazione è quello di un router PE; certo, non è impossibile, ma ha implicazioni sia gestionali sia di prestazioni.

I tunnel MPLS-in-IP e MPLS-in-GRE sono specificati in [MPLS-in-IP-GRE]. Se si desidera usare tali tunnel per trasportare pacchetti VPN, devono essere pienamente comprese le considerazioni sulla sicurezza descritte nella sezione 8 di quel documento. Qualsiasi implementazione VPN IP BGP/MPLS che consenta a pacchetti VPN di essere tunnelizzati come ivi descritto DEVE contenere un'implementazione IPsec utilizzabile come indicato. Se il tunnel non è protetto da IPsec, allora la tecnica di filtraggio degli indirizzi IP ai router di confine, descritta nella sezione 8.2 di quel documento, è l'unico mezzo per garantire che un pacchetto che emerge dal tunnel a un particolare PE di uscita sia stato effettivamente inserito nel tunnel dal nodo di testa di tunnel appropriato (cioè che il pacchetto non abbia un indirizzo sorgente contraffatto — spoofed source address). Poiché i router di confine filtrano frequentemente solo gli indirizzi sorgente, il filtraggio dei pacchetti potrebbe non essere efficace a meno che il PE di uscita non possa verificare l'indirizzo IP sorgente di qualsiasi pacchetto tunnelizzato che riceve, e confrontarlo con un elenco di indirizzi di testa di tunnel valide. Qualsiasi implementazione che consenta l'uso di tunnel MPLS-in-IP e/o MPLS-in-GRE senza IPsec DEVE consentire al PE di uscita di convalidare in tal modo l'indirizzo IP sorgente di qualsiasi pacchetto tunnelizzato ricevuto.

Nel caso in cui molteplici router CE siano collegati a un router PE tramite un'interfaccia LAN, per garantire un'adeguata sicurezza deve essere soddisfatta una delle due seguenti condizioni:

1. Tutti i router CE sulla LAN appartengono allo stesso VPN, oppure

2. Un switch LAN fidato e sicuro divide la LAN in molteplici VLAN, ciascuna contenente solo i sistemi di un singolo VPN; in tal caso, lo switch applicherà il tag (tag) VLAN appropriato a qualsiasi pacchetto prima di inoltrarlo al router PE.

La privacy crittografica (cryptographic privacy) non è fornita né da questa architettura né dai VPN Frame Relay o ATM. Queste architetture sono tutte compatibili con l'uso della crittografia (cryptography) su base CE-CE, se desiderato.

L'uso della crittografia su base PE-PE è lasciato a ulteriori studi.

13.2. Control Plane (Control Plane)

La sicurezza del data plane della sezione precedente dipende dalla sicurezza del control plane. Per garantire la sicurezza, né connessioni BGP né connessioni LDP devono essere stabilite con peer non fidati. L'opzione di autenticazione MD5 di TCP/IP [TCP-MD5] deve essere usata con entrambi i protocolli. Il protocollo di instradamento all'interno della rete del SP deve essere protetto in modo simile.

13.3. Sicurezza dei dispositivi P e PE (Security of P and PE Devices)

Se la sicurezza fisica di questi dispositivi è compromessa, la sicurezza del data plane può essere a sua volta compromessa.

Devono essere adottate le misure consuete per garantire che il traffico IP proveniente da Internet pubblico non possa essere usato per modificare la configurazione di questi dispositivi, né per lanciare attacchi di negazione del servizio (Denial of Service) contro di essi.