1. Introduction (Introduzione)

Questo documento descrive un metodo mediante il quale un service provider può utilizzare una dorsale IP per fornire IP Virtual Private Networks (VPN) ai propri clienti. Questo metodo utilizza un "modello di peering", in cui il router customer edge (CE) invia le proprie route al router provider edge (PE). Il Border Gateway Protocol (BGP) [BGP, BGP-MP] viene quindi utilizzato dal service provider per scambiare le route di una particolare VPN tra i router PE collegati a tale VPN. Ciò avviene in modo da garantire che le route di VPN diverse rimangano distinte e separate, anche se due VPN hanno uno spazio di indirizzi sovrapposto. I router PE distribuiscono le route da altri router CE in una particolare VPN ai router CE in quella VPN. I router CE non fanno peer tra loro, quindi non c'è alcun "overlay" visibile all'algoritmo di routing della VPN. Il termine "IP" in "IP VPN" viene utilizzato per indicare che il PE riceve datagrammi IP dal CE, esamina le intestazioni IP e li instrada di conseguenza.

A ogni route all'interno di una VPN viene assegnata un'etichetta Multiprotocol Label Switching (MPLS) [MPLS-ARCH, MPLS-BGP, MPLS-ENCAPS]; quando BGP distribuisce una route VPN, distribuisce anche un'etichetta MPLS per quella route. Prima che un pacchetto di dati del cliente attraversi la dorsale del service provider, viene incapsulato con l'etichetta MPLS che corrisponde alla route VPN del cliente che meglio corrisponde all'indirizzo di destinazione del pacchetto. Questo pacchetto MPLS viene ulteriormente incapsulato (ad esempio, con un'altra etichetta MPLS o con un'intestazione IP o Generic Routing Encapsulation (GRE) [MPLS-in-IP-GRE]) in modo che possa essere incanalato attraverso la dorsale fino al router PE appropriato. Pertanto, i router core della dorsale non hanno bisogno di conoscere le route VPN.

L'obiettivo principale di questo metodo è supportare il caso in cui il cliente ottenga servizi di dorsale IP da uno o più service provider con cui intrattiene relazioni contrattuali. Il cliente può essere un'impresa, un gruppo di imprese che necessita di un'extranet, un Internet Service Provider, un Application Service Provider, un altro service provider VPN che utilizza questo stesso metodo per fornire VPN ai propri clienti, ecc. Questo metodo rende molto semplice per il cliente l'utilizzo dei servizi di dorsale. È anche molto scalabile e flessibile per il service provider e consente al service provider di aggiungere valore.

1.1. Virtual Private Networks (Reti Private Virtuali)

Consideriamo un insieme di "siti" collegati a una rete comune, che chiamiamo "dorsale". Applichiamo ora alcune policy per creare una serie di sottoinsiemi di questa raccolta e stabiliamo la seguente regola: due siti possono avere connettività IP tramite questa dorsale se e solo se sono entrambi contenuti in almeno uno di questi sottoinsiemi.

Questi sottoinsiemi sono Virtual Private Networks (VPN). Due siti hanno connettività IP sulla dorsale comune solo se esiste una VPN che contiene entrambi i siti. Due siti che non hanno alcuna VPN in comune non hanno connettività su questa dorsale.

Se tutti i siti in una VPN sono di proprietà della stessa impresa, la VPN può essere considerata come la "intranet" aziendale. Se i vari siti in una VPN sono di proprietà di imprese diverse, la VPN può essere considerata come una "extranet". Un sito può trovarsi in più di una VPN; ad esempio, in una intranet e in diverse extranet. In generale, quando usiamo il termine "VPN", non faremo distinzione tra intranet ed extranet.

Chiamiamo il proprietario dei siti il "cliente". Chiamiamo il proprietario/gestore della dorsale il "Service Provider" (SP). Il cliente ottiene il "servizio VPN" dall'SP.

Il cliente può essere una singola impresa, un gruppo di imprese, un Internet Service Provider, un Application Service Provider, un altro SP che offre lo stesso tipo di servizio VPN ai propri clienti, ecc.

Le policy che determinano se una particolare raccolta di siti è una VPN sono le policy del cliente. Alcuni clienti desiderano che l'SP sia pienamente responsabile dell'implementazione di queste policy. Altri clienti potrebbero voler condividere la responsabilità dell'implementazione di queste policy con l'SP. Questo documento specifica i meccanismi che possono essere utilizzati per implementare queste policy. I meccanismi descritti sono abbastanza generali da consentire l'implementazione di queste policy da parte del solo SP o congiuntamente dal cliente VPN e dall'SP. La maggior parte della discussione si concentra però sul primo caso.

I meccanismi discussi in questo documento consentono l'implementazione di un'ampia gamma di policy. Ad esempio, all'interno di una data VPN, a ogni sito può essere consentito di avere una rotta diretta verso ogni altro sito ("full mesh"). In alternativa, si può imporre che il traffico tra determinate coppie di siti venga instradato tramite un terzo sito. Ciò potrebbe essere utile, ad esempio, se si desidera che il traffico tra una coppia di siti passi attraverso un firewall e il firewall si trovi presso il terzo sito.

In questo documento, limitiamo la discussione al caso in cui il cliente acquisti esplicitamente il servizio VPN da un SP o da un insieme di SP che hanno concordato di collaborare per fornire il servizio VPN. Cioè, il cliente non sta semplicemente acquistando l'accesso a Internet da un SP e il traffico VPN non passa attraverso una raccolta casuale di reti SP interconnesse.

Limitiamo inoltre la discussione al caso in cui la dorsale fornisca un servizio IP al cliente, piuttosto che fornire un servizio di Livello 2 come Frame Relay, Asynchronous Transfer Mode (ATM), Ethernet, High Level Data Link Control (HDLC) o Point-to-Point Protocol (PPP). Il cliente può connettersi alla dorsale tramite uno di questi servizi di Livello 2 (o altri), ma il servizio di Livello 2 termina al "bordo" della dorsale, dove i datagrammi IP del cliente vengono rimossi da qualsiasi incapsulamento di Livello 2.

Nel resto di questa introduzione, specifichiamo alcune proprietà che le VPN dovrebbero possedere. Il resto del documento specifica un insieme di meccanismi che possono essere implementati per fornire un modello di VPN che possieda tutte queste proprietà. Questa sezione introduce anche una terminologia tecnica utilizzata nel resto del documento.

1.2. Customer Edge and Provider Edge (Customer Edge e Provider Edge)

I router possono essere collegati tra loro, o a sistemi terminali, in vari modi: connessioni PPP, ATM Virtual Circuits (VC), Frame Relay VC, interfacce Ethernet, Virtual Local Area Networks (VLAN) su interfacce Ethernet, tunnel GRE, tunnel Layer 2 Tunneling Protocol (L2TP), tunnel IPsec, ecc. Utilizzeremo il termine "attachment circuit" (circuito di collegamento) per riferirci a qualsiasi mezzo di collegamento a un router. Un attachment circuit può essere il tipo di connessione che viene solitamente considerata un "data link", oppure può essere un tunnel di qualsiasi tipo; ciò che conta è che due dispositivi possano essere peer a livello di rete tramite l'attachment circuit.

Ogni sito VPN deve contenere uno o più dispositivi Customer Edge (CE). Ogni dispositivo CE è collegato, tramite una sorta di attachment circuit, a uno o più router Provider Edge (PE).

I router nella rete SP che non sono collegati ai dispositivi CE sono noti come "router P".

I dispositivi CE possono essere host o router. Nel caso tipico, un sito contiene uno o più router, alcuni dei quali sono collegati ai router PE. I router del sito che si collegano ai router PE sono i dispositivi CE, o "router CE". Tuttavia, nulla impedisce a un host non router di connettersi direttamente a un router PE. In tal caso, tale host è un dispositivo CE.

A volte ciò che è fisicamente collegato a un router PE è uno switch di Livello 2. In questo caso, non diciamo che lo switch di Livello 2 è un dispositivo CE. Piuttosto, i dispositivi CE sono gli host e i router che comunicano con il router PE attraverso lo switch di Livello 2; l'infrastruttura di Livello 2 è trasparente. Se l'infrastruttura di Livello 2 fornisce un servizio multipunto, allora più dispositivi CE possono essere collegati al router PE tramite lo stesso attachment circuit.

I dispositivi CE fanno logicamente parte della VPN del cliente. I router PE e P fanno logicamente parte della rete SP.

L'attachment circuit su cui viaggia un pacchetto quando va dal CE al PE è noto come "attachment circuit in ingresso" di quel pacchetto, e quel PE è noto come "PE in ingresso" del pacchetto. L'attachment circuit su cui viaggia un pacchetto quando va dal PE al CE è noto come "attachment circuit in uscita" di quel pacchetto, e quel PE è noto come "PE in uscita" del pacchetto.

Se un router PE è collegato a un dispositivo CE che appartiene a un particolare sito VPN, diremo che il router PE è collegato a quella VPN. Allo stesso modo, se un router PE è collegato a un dispositivo CE che appartiene a un particolare sito, diremo che il router PE è collegato a quel sito.

Quando il dispositivo CE è un router, è un routing peer del PE a cui è collegato, ma non è un routing peer dei router CE in altri siti. I router in siti diversi non scambiano informazioni di routing direttamente tra loro; infatti, non hanno nemmeno bisogno di conoscersi. Pertanto, il cliente non ha una dorsale o una "dorsale virtuale" da gestire e non deve occuparsi di problemi di routing inter-sito. In altre parole, nello schema descritto in questo documento, una VPN non è un "overlay" sulla rete SP.

Per quanto riguarda la gestione dei dispositivi edge, viene mantenuto un chiaro confine di gestione tra l'SP e il suo cliente. Il cliente non necessita di accesso ai router PE o P per scopi di gestione e l'SP non necessita di accesso ai dispositivi CE per scopi di gestione.

1.3. VPNs with Overlapping Address Spaces (VPN con spazi di indirizzi sovrapposti)

Se due VPN non hanno siti in comune, possono avere spazi di indirizzi sovrapposti. Cioè, un dato indirizzo può essere utilizzato nella VPN V1 come indirizzo del sistema S1, ma nella VPN V2 come indirizzo di un sistema completamente diverso S2. Questa è una situazione comune quando ogni VPN utilizza lo spazio di indirizzi privato RFC 1918. Naturalmente, all'interno di ogni VPN, ogni indirizzo deve essere non ambiguo.

Anche due VPN che hanno siti in comune possono avere spazi di indirizzi sovrapposti, purché non vi sia la necessità che i sistemi con tali indirizzi comunichino con i sistemi nei siti comuni.

1.4. VPNs with Different Routes to the Same System (VPN con route diverse verso lo stesso sistema)

Sebbene un sito possa trovarsi in più di una VPN, non è necessario che il percorso verso un dato sistema in quel sito sia lo stesso in tutte le VPN. Supponiamo ad esempio di avere una intranet composta dai siti A, B e C e una extranet composta da A, B, C e un sito "esterno" D. Supponiamo che ci sia un server nel sito A che vogliamo rendere accessibile ai client di B, C o D. Supponiamo anche che ci sia un firewall nel sito B. Vogliamo che tutto il traffico da D al server passi attraverso il firewall, in modo che il controllo degli accessi possa essere applicato al traffico dell'extranet. Tuttavia, non vogliamo che il traffico da C passi attraverso il firewall nel tragitto verso il server, poiché si tratta di traffico intranet.

Possono essere stabiliti due percorsi verso il server. Un percorso è utilizzato dai siti B e C e porta il traffico direttamente al sito A. Il secondo percorso è utilizzato dal sito D e porta il traffico al firewall nel sito B. Se il firewall consente al traffico di passare, questo appare quindi come traffico proveniente dal sito B e segue il percorso verso il sito A.

1.5. SP Backbone Routers (Router dorsali SP)

La dorsale SP è costituita dai router PE e da altri router ("router P") che non sono collegati ai dispositivi CE.

Se ogni router nella dorsale SP dovesse mantenere le informazioni di routing per tutte le VPN supportate dall'SP, ci sarebbero seri problemi di scalabilità; il numero di siti che potrebbero essere supportati sarebbe limitato dalla quantità di informazioni di routing che un singolo router potrebbe contenere. Pertanto, è importante che le informazioni di routing su una particolare VPN debbano essere presenti solo nei router PE collegati a quella VPN. In particolare, i router P non dovrebbero aver bisogno di avere alcuna informazione di routing specifica per VPN. (Quando si considera il routing multicast, questa condizione potrebbe dover essere leggermente allentata. Questo non è discusso ulteriormente qui, ma è esplorato in [VPN-MCAST].)

Quindi, proprio come i proprietari di VPN non hanno una dorsale o una "dorsale virtuale" da gestire, l'SP stesso non gestisce una dorsale o una "dorsale virtuale" separata per ogni VPN. Il routing inter-sito nella dorsale è ottimale (nei limiti delle policy utilizzate per formare le VPN) e non è vincolato da alcuna "topologia virtuale" artificiale di tunnel.

La Sezione 10 discute alcuni problemi speciali che sorgono quando la dorsale si estende su più provider di servizi.

1.6. Security (Sicurezza)

Le VPN di questo tipo, come discusso qui, sono intese per fornire un livello di sicurezza equivalente a quello che si può ottenere quando si utilizza una dorsale di Livello 2 (ad esempio, Frame Relay), anche se non vengono utilizzate misure di sicurezza crittografica. Cioè, in assenza di una configurazione errata o di un'interconnessione deliberata di diverse VPN, è impossibile per un sistema in una VPN ottenere l'accesso a un sistema in un'altra VPN. Naturalmente, i metodi qui descritti non crittografano i dati per la riservatezza, né forniscono un modo per determinare se i dati sono stati alterati durante il transito. Se queste funzionalità sono desiderate, devono essere applicate misure crittografiche in aggiunta (vedi, ad esempio, [MPLS/BGP-IPsec]). La sicurezza è discussa più in dettaglio nella Sezione 13.