13. Security Considerations (Considerazioni sulla sicurezza)

13.1. Data Plane (Piano dati)

Per sicurezza nel "piano dati", intendiamo la protezione contro le seguenti possibilità:

Pacchetti provenienti dall'interno di una VPN vengono inoltrati a un sito esterno alla VPN, ma in un modo che non è consentito dalle policy della VPN.
Pacchetti provenienti dall'esterno di una VPN entrano in un sito della VPN, ma in un modo che non è consentito dalle policy della VPN.

Alle seguenti condizioni:

i router dorsali non accettano pacchetti etichettati tramite un particolare collegamento dati a meno che non sia noto che tale collegamento dati si connette solo a un sistema fidato, o a meno che non sia noto che tali pacchetti lasceranno la dorsale prima che l'intestazione IP o qualsiasi etichetta inferiore nella pila venga ispezionata, e
le rotte VPN-IPv4 etichettate non vengono accettate da peer di routing non fidati o inaffidabili,
il piano di controllo non è stato compromesso da un attacco riuscito,

questa architettura fornisce una sicurezza del piano dati praticamente identica a quella fornita alle VPN dalle dorsali Frame Relay o ATM. Se l'apparecchiatura sotto il controllo dell'SP è configurata correttamente, i dati non entreranno o usciranno da una VPN a meno che non siano autorizzati a farlo.

La condizione 1 sopra può essere definita più precisamente. I pacchetti etichettati ricevuti da un particolare vicino devono essere scartati a meno che non sia vera una delle due condizioni seguenti:

l'etichetta superiore del pacchetto ha un valore di etichetta che il sistema ricevente ha distribuito a quel vicino, oppure
l'etichetta superiore del pacchetto ha un valore di etichetta che il sistema ricevente ha distribuito a un sistema oltre quel vicino (cioè, quando è noto che il percorso dal sistema a cui è stata distribuita l'etichetta al sistema ricevente può passare attraverso quel vicino).

La condizione 2 sopra è di massima preoccupazione nel caso di VPN inter-provider (vedi Sezione 10). Per le VPN inter-provider costruite secondo lo schema (b) della Sezione 10, la condizione 2 è facile da verificare. (I problemi di sicurezza nell'uso dello schema (c) della Sezione 10 sono oggetto di ulteriori studi.)

Vale la pena notare che l'uso di MPLS rende la fornitura della sicurezza del piano dati molto più semplice rispetto al tentativo di utilizzare una qualche forma di tunneling IP al posto dell'etichetta esterna MPLS. È molto semplice per un router di confine rifiutare di accettare pacchetti etichettati a meno che la prima condizione sopra non si applichi ad esso. È molto più difficile configurare un router per rifiutare di accettare pacchetti IP se si tratta di pacchetti tunnel IP la cui destinazione è un router PE; non è certamente impossibile farlo, ma ha implicazioni sia amministrative che di prestazioni.

I tunnel MPLS-in-IP e MPLS-in-GRE sono specificati in [MPLS-in-IP-GRE]. Se si desidera uno di questi tipi di tunnel per trasportare pacchetti VPN, allora le considerazioni sulla sicurezza descritte nella Sezione 8 di quel documento devono essere completamente comprese. Qualsiasi implementazione VPN IP BGP/MPLS che consente ai pacchetti VPN di essere incanalati come descritto in quel documento DEVE (MUST) contenere un'implementazione di IPsec che deve essere utilizzata come descritto in esso. Se il tunnel non è protetto da IPsec, allora le tecniche di filtraggio degli indirizzi IP sui router di confine descritte nella Sezione 8.2 di quel documento sono l'unico modo per garantire che un pacchetto che esce da un tunnel presso un particolare PE di uscita sia stato effettivamente inserito nel tunnel dal nodo di testa del tunnel corretto (cioè, che il pacchetto non abbia un indirizzo sorgente falsificato). Poiché i router di confine spesso filtrano solo sull'indirizzo sorgente, a meno che il PE di uscita non possa ispezionare l'indirizzo IP sorgente di tutti i pacchetti tunnel che riceve e confrontarlo con un elenco di indirizzi IP che sono indirizzi di testa del tunnel validi, il filtraggio dei pacchetti potrebbe essere inefficace. Qualsiasi implementazione che consente l'uso di tunnel MPLS-in-IP e/o MPLS-in-GRE senza IPsec DEVE (MUST) consentire al PE di uscita di convalidare l'indirizzo IP sorgente di qualsiasi pacchetto tunnel che riceve in questo modo. Se più router CE sono collegati a un router PE tramite un'interfaccia LAN, per garantire una sicurezza adeguata, una delle seguenti condizioni deve essere vera:

tutti i router CE sulla LAN appartengono alla stessa VPN, oppure
un LAN switch fidato e sicuro partiziona la LAN in più VLAN, in modo tale che ogni VLAN contenga solo sistemi di una singola VPN; in questo caso, lo switch allegherà l'appropriato tag VLAN a qualsiasi pacchetto prima di inoltrarlo al router PE.

Questa architettura non fornisce riservatezza crittografica, né lo fanno le VPN Frame Relay o ATM. Tutte queste architetture sono compatibili con l'uso della crittografia basata su CE-CE, se ciò è desiderato.

L'uso della crittografia basata su PE-PE è oggetto di ulteriori studi.

13.2. Control Plane (Piano di controllo)

La sicurezza del piano dati della sezione precedente dipende dalla sicurezza del piano di controllo. Per garantire la sicurezza, non dovrebbero essere stabilite connessioni BGP o LDP con peer non fidati. Entrambi i protocolli dovrebbero utilizzare l'opzione di autenticazione TCP/IP MD5 [TCP-MD5]. I protocolli di routing all'interno della rete SP dovrebbero essere protetti in modo simile.

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

Se la sicurezza fisica di questi dispositivi è compromessa, anche la sicurezza del piano dati potrebbe essere compromessa.

Dovrebbero essere prese le solite misure per garantire che il traffico IP proveniente dall'Internet pubblico non possa essere utilizzato per modificare la configurazione di questi dispositivi o per lanciare un attacco Denial of Service contro di essi.