1. Introduzione

1. Introduzione (Introduction)

Questo documento descrive un metodo che consente a un fornitore di servizi (Service Provider, SP) di utilizzare il proprio backbone IP (backbone) per fornire reti private virtuali IP (Virtual Private Networks, VPN) ai propri clienti. Il metodo impiega un "modello peer" (peer model): i router di frontiera del cliente (Customer Edge router, router CE) inviano i propri instradamenti (route) al router di frontiera del fornitore (Provider Edge router, router PE); l'algoritmo di instradamento del cliente non vede alcun "overlay" (overlay), e i router CE di siti diversi non sono peer tra loro. L'IP nel "IP VPN" significa che il PE riceve datagrammi IP (datagram) dal CE, esamina il relativo header IP (header) e inoltra di conseguenza.

Gli instradamenti di ciascun VPN ricevono un'etichetta (label) MPLS (Multiprotocol Label Switching) [MPLS-ARCH, MPLS-BGP, MPLS-ENCAPS]; quando il BGP (Border Gateway Protocol) [BGP, BGP-MP] distribuisce un instradamento VPN, distribuisce simultaneamente un'etichetta MPLS per tale instradamento. Prima che un pacchetto dati (packet) del cliente attraversi il backbone del fornitore, viene incapsulato con un'etichetta MPLS che corrisponde all'instradamento nel VPN del cliente che meglio corrisponde all'indirizzo di destinazione (destination address) del pacchetto. Il pacchetto MPLS viene quindi ulteriormente incapsulato (ad esempio con un'altra etichetta MPLS, o con un header di tunnel IP o GRE — tunnel header [MPLS-in-IP-GRE]) e attraversa il backbone tramite un tunnel (tunnel) fino al router PE corretto. Pertanto, i router di core del backbone (backbone core router, cioè i router P) non necessitano di conoscere alcun instradamento VPN.

L'obiettivo principale di questo metodo è supportare il caso in cui un cliente ottenga servizi di backbone IP da uno o più fornitori di servizi con cui ha un rapporto contrattuale. Il cliente può essere un'impresa, un gruppo di imprese che necessita di un extranet, un Internet Service Provider, un application service provider, o un altro fornitore di VPN che utilizza lo stesso metodo per offrire VPN ai propri clienti, ecc. Il metodo consente al cliente di utilizzare il servizio di backbone in modo molto semplice; per il fornitore di servizi offre inoltre una buona scalabilità e flessibilità, e consente al fornitore di aggiungere valore.

1.1. Reti private virtuali (Virtual Private Networks)

Consideriamo un insieme di "siti" (site) collegati a una rete comune che chiameremo "backbone" (backbone). Applichiamo una politica (policy) che suddivide tale insieme di siti in sottoinsiemi, con la regola per cui due siti possono stabilire una interconnessione IP tramite il backbone solo se entrambi appartengono a uno di quei sottoinsiemi.

Tali sottoinsiemi sono le reti private virtuali (VPN). Due siti hanno connettività (connectivity) IP tramite il backbone comune solo se esiste un VPN che contiene entrambi. Se due siti non condividono alcun VPN, non hanno alcuna connettività su tale backbone.

Se tutti i siti di un VPN appartengono a una stessa impresa, il VPN può essere considerato una "intranet"; se i siti di un VPN appartengono a imprese diverse, il VPN può essere considerato un "extranet". Un sito può appartenere a più VPN, ad esempio sia a una intranet che a più extranet. In generale, quando questo documento usa il termine "VPN", non fa distinzione tra intranet ed extranet.

Il proprietario di un sito è detto "cliente" (customer), il proprietario o gestore del backbone è detto "fornitore di servizi" (Service Provider, SP). Il cliente ottiene dal SP un "servizio VPN" (VPN service).

Un cliente può essere una singola impresa, un gruppo di imprese, un Internet Service Provider, un application service provider, o un altro SP che offre ai propri clienti un servizio VPN analogo, ecc.

La politica che determina se un insieme di siti costituisce un VPN appartiene al cliente. Alcuni clienti desiderano che tale politica sia interamente realizzata dal SP; altri possono voler condividere la responsabilità con il SP. Questo documento specifica meccanismi utilizzabili per realizzare tali politiche. I meccanismi descritti sono abbastanza generici da supportare sia il solo SP che la collaborazione tra cliente VPN e SP; l'attenzione è tuttavia posta principalmente sul primo caso.

I meccanismi qui discussi consentono di realizzare un'ampia gamma di politiche. Ad esempio, all'interno di un VPN, si può consentire a ciascun sito di avere un instradamento diretto verso ciascun altro sito ("full mesh"); oppure si può forzare il traffico (traffic) tra certe coppie di siti a passare per un terzo sito. Ciò è utile, ad esempio, se si desidera che il traffico tra una coppia di siti passi per un firewall (firewall) situato su un terzo sito.

In questo documento, limitiamo la discussione al caso in cui il cliente acquisti esplicitamente un servizio VPN da un SP, o da un gruppo di SP che si sono accordati per fornire il VPN. In altre parole, il cliente non acquista semplicemente un accesso Internet (Internet access) dal SP, e il traffico VPN non attraversa un insieme di reti (networks) di SP interconnesse casualmente.

Limitiamo inoltre la discussione al caso in cui il backbone offra al cliente un servizio IP (anziché un servizio di livello 2 — layer 2 — come Frame Relay, ATM, Ethernet, HDLC o PPP). Il cliente può utilizzare uno di questi (o altri) servizi di livello 2 per connettersi al backbone, ma tale servizio di livello 2 termina al "bordo" (edge) del backbone, dove i datagrammi IP del cliente vengono estratti da qualsiasi incapsulamento (encapsulation) di livello 2.

Nel resto di questa introduzione, enunciamo innanzitutto alcune proprietà che i VPN dovrebbero possedere; il resto del documento specifica un insieme di meccanismi distribuibili per fornire un modello (model) di VPN dotato di tutte queste proprietà. Questa sezione introduce anche alcuni termini tecnici usati nel resto del documento.

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

I router (router) possono essere collegati tra loro, o a sistemi terminali (end system), in molti modi diversi: connessioni PPP, circuiti virtuali (Virtual Circuit, VC) ATM, VC Frame Relay, interfacce Ethernet, VLAN (Virtual Local Area Network) su interfaccia Ethernet, tunnel GRE, tunnel L2TP (Layer 2 Tunneling Protocol), tunnel IPsec, ecc. Usiamo il termine "circuito di attacco" (attachment circuit) come termine generico per indicare un mezzo di questo tipo per collegarsi a un router. Un circuito di attacco può essere una connessione solitamente vista come "collegamento dati" (data link), oppure un tunnel; l'essenziale è che due dispositivi possano diventare peer (peer) di livello di rete (network layer) tramite tale circuito.

Ogni sito VPN deve contenere uno o più dispositivi (device) di bordo cliente (Customer Edge, CE). Ciascun dispositivo CE è collegato tramite un circuito di attacco a uno o più router PE.

I router nella rete SP non collegati a dispositivi CE sono detti router P (P router).

Un dispositivo CE può essere un host (host) o un router. Nel caso tipico, un sito contiene diversi router, alcuni dei quali collegati a router PE. Il router di sito collegato a un router PE è il dispositivo CE, o "router CE". Nulla impedisce tuttavia che un host privo di funzioni di instradamento sia direttamente collegato a un router PE — in tal caso, tale host è un dispositivo CE.

Talvolta, è uno switch di livello 2 (layer 2 switch) a essere fisicamente collegato al router PE. In questo caso, non consideriamo tale switch di livello 2 un dispositivo CE; piuttosto, i dispositivi CE sono gli host e i router che comunicano con il router PE tramite tale switch di livello 2, essendo l'infrastruttura (infrastructure) di livello 2 trasparente. Se l'infrastruttura di livello 2 offre un servizio multipoint (multipoint), più dispositivi CE possono essere collegati al router PE tramite lo stesso circuito di attacco.

I dispositivi CE appartengono logicamente al VPN del cliente; i router PE e P appartengono logicamente alla rete del SP.

Il circuito di attacco percorso da un pacchetto dal CE al PE è detto "circuito di attacco di ingresso" (ingress attachment circuit) di quel pacchetto, e tale PE è il "PE di ingresso" (ingress PE); il circuito dal PE al CE è il "circuito di attacco di uscita" (egress attachment circuit), e tale PE è il "PE di uscita" (egress PE).

Se un router PE è collegato a un dispositivo CE in un sito di un determinato VPN, diciamo che tale router PE è "collegato a quel particolare VPN"; analogamente, se un router PE è collegato a un dispositivo CE in un determinato sito, diciamo che è "collegato a quel particolare sito".

Se il dispositivo CE è un router, è il peer di instradamento del (o dei) PE a cui è collegato, ma non dei router CE di altri siti. I router di siti diversi non scambiano direttamente informazioni di instradamento (routing information) tra loro; in effetti, non devono nemmeno conoscersi reciprocamente. Il cliente non ha quindi né un backbone né un "backbone virtuale" (virtual backbone) da gestire, e non deve occuparsi di alcun instradamento tra siti (inter-site routing). In altre parole, nel contesto qui descritto, il VPN non è un "overlay" (overlay) sopra la rete SP.

Per quanto riguarda la gestione dei dispositivi di bordo, esiste un confine di gestione netto tra SP e cliente. Il cliente non necessita di accedere ai router PE o P per scopi di gestione, e il SP non necessita di accedere ai dispositivi CE per scopi di gestione.

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

Se due VPN non hanno siti in comune, possono avere spazi di indirizzamento (address space) sovrapposti. Ciò significa che un dato indirizzo può essere usato nel VPN V1 come indirizzo del sistema (system) S1 e nel VPN V2 come indirizzo di un sistema S2 del tutto diverso. Ciò è frequente quando ciascun VPN usa lo spazio di indirizzamento privato (private address space) della RFC 1918. Naturalmente, all'interno di ciascun VPN, ciascun indirizzo deve essere non ambiguo.

Anche se due VPN hanno un sito in comune, possono avere spazi di indirizzamento sovrapposti, purché non sia richiesta alcuna comunicazione tra i sistemi aventi tali indirizzi e i sistemi del sito comune.

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

Sebbene un sito possa appartenere a più VPN, la route verso un dato sistema di quel sito non è necessariamente la stessa in tutti i VPN. Supponiamo, ad esempio, un'intranet composta dai siti A, B, C e un extranet composta da A, B, C e da un sito "esterno" (foreign) D. Supponiamo che nel sito A vi sia un server (server) che deve essere utilizzato dai client (client) di B, C o D. Supponiamo inoltre che nel sito B vi sia un firewall. Vogliamo che tutto il traffico da D a tale server passi per tale firewall, per controllare l'accesso per il traffico proveniente dall'extranet. Ma non vogliamo che il traffico da C a tale server passi per il firewall, poiché si tratta di traffico di intranet.

Si possono configurare due route per tale server. Una route è usata dai siti B e C, indirizzando il traffico direttamente al sito A; la seconda route è usata dal sito D, indirizzando invece il traffico al firewall del sito B. Se il firewall consente il traffico, quest'ultimo apparirà proveniente dal sito B e sarà inoltrato lungo la route verso il sito A.

1.5. Router di backbone SP (SP Backbone Routers)

Il backbone del SP è composto dai router PE e da altri router non collegati a dispositivi CE (i "router P").

Se ogni router nel backbone SP dovesse mantenere le informazioni di instradamento (routing information) di tutti i VPN supportati dal SP, sorgerebbe un grave problema di scalabilità (scalability) — il numero di siti supportabili sarebbe limitato dalla quantità di informazioni di instradamento che un singolo router può memorizzare. Pertanto, è essenziale che le informazioni di instradamento relative a un determinato VPN esistano solo nei router PE collegati a quel VPN. In particolare, i router P non necessitano affatto di alcuna informazione di instradamento "per VPN". (Questa condizione potrebbe dover essere attenuata per l'instradamento multicast (multicast routing); non è qui ulteriormente discusso, ma se ne occupa [VPN-MCAST].)

Così come il proprietario di un VPN non ha un backbone né un "backbone virtuale" da gestire, anche il SP stesso non deve gestire un backbone separato o un "backbone virtuale" per ciascun VPN. L'instradamento tra siti all'interno del backbone è ottimale (entro i limiti delle politiche usate per costruire il VPN) e non è vincolato da alcuna "topologia virtuale" (virtual topology) di tunnel artificiale.

La sezione 10 discute alcuni problemi particolari che sorgono quando il backbone si estende su più fornitori di servizi.

1.6. Sicurezza (Security)

I VPN di questo tipo sono progettati per offrire un livello di sicurezza paragonabile a quello ottenibile con un backbone di livello 2 (come il Frame Relay), anche senza misure di cifratura di sicurezza. Ciò significa che, in assenza di configurazioni errate e senza interconnessione deliberata di VPN diversi, un sistema in un VPN non può accedere a un sistema in un altro VPN. Naturalmente, il metodo qui descritto non cifra i dati per proteggerli e non fornisce alcun mezzo per rilevare se i dati siano stati alterati in transito. Se tali capacità sono necessarie, devono essere applicate separatamente misure di cifratura. (Si veda ad esempio [MPLS/BGP-IPsec].) La sezione 13 discute la sicurezza in maggiore dettaglio.