1. Introduction
1. Introduction
Ce document décrit une méthode permettant à un fournisseur de services (Service Provider, ou SP) d'utiliser son réseau dorsal IP (backbone) pour fournir à ses clients des réseaux privés virtuels IP (Virtual Private Networks, ou VPN). Cette méthode utilise un « modèle pair-à-pair » (peer model) : les routeurs de bordure client (Customer Edge router, ou routeur CE) envoient leurs routes au routeur de bordure fournisseur (Provider Edge router, ou routeur PE) ; l'algorithme de routage du client ne voit aucune « superposition » (overlay), et les routeurs CE de sites différents ne sont pas en relation de pairs entre eux. Le « IP » dans « IP VPN » signifie que le PE reçoit des datagrammes IP du CE, examine leur en-tête IP, et achemine en conséquence.
Les routes de chaque VPN se voient attribuer une étiquette (label) MPLS (Multiprotocol Label Switching, ou commutation d'étiquettes multi-protocoles) [MPLS-ARCH, MPLS-BGP, MPLS-ENCAPS] ; lorsque BGP (Border Gateway Protocol, ou protocole de passerelle frontière) [BGP, BGP-MP] distribue une route VPN, il distribue également une étiquette MPLS pour cette route. Avant de traverser le réseau dorsal du fournisseur, un paquet (packet) de client est encapsulé avec une étiquette MPLS correspondant à la route du VPN qui correspond le mieux à l'adresse de destination du paquet. Le paquet MPLS est ensuite encapsulé plus avant (par exemple avec une autre étiquette MPLS, ou avec une en-tête de tunnel IP ou GRE — Generic Routing Encapsulation) et traverse le réseau dorsal via un tunnel (tunnel) jusqu'au routeur PE approprié. Ainsi, les routeurs centraux du réseau dorsal (routeurs P, ou routeurs de cœur de réseau dorsal) n'ont pas besoin de connaître les routes VPN.
L'objectif principal de cette méthode est de prendre en charge le cas où un client obtient un service de réseau dorsal IP auprès d'un ou plusieurs fournisseurs de services avec lesquels il entretient une relation contractuelle. Le client peut être une entreprise, un groupe d'entreprises nécessitant un extranet, un fournisseur d'accès Internet (Internet Service Provider), un fournisseur de services applicatifs (application service provider), ou un autre fournisseur de VPN utilisant la même méthode pour offrir des VPN à ses propres clients, etc. La méthode permet au client d'utiliser très simplement le service de réseau dorsal ; elle offre également au fournisseur de services une bonne évolutivité et flexibilité, et lui permet d'ajouter de la valeur.
1.1. Réseaux privés virtuels (Virtual Private Networks)
Considérons un ensemble de « sites » connectés à un réseau commun que nous appellerons le « réseau dorsal » (backbone). Imposons une politique (policy) qui divise cet ensemble de sites en sous-ensembles, avec la règle selon laquelle deux sites ne peuvent obtenir une interconnexion IP via le réseau dorsal que s'ils appartiennent tous deux à l'un de ces sous-ensembles.
Ces sous-ensembles sont des réseaux privés virtuels (VPN). Deux sites n'ont de connectivité (connectivity) IP via le réseau dorsal commun que s'il existe un VPN contenant les deux. S'ils n'ont aucun VPN en commun, ils n'ont aucune connectivité sur ce réseau dorsal.
Si tous les sites d'un VPN appartiennent à une même entreprise, le VPN peut être vu comme un « intranet » ; si les sites d'un VPN appartiennent à des entreprises différentes, le VPN peut être vu comme un « extranet ». Un site peut appartenir à plusieurs VPN, par exemple à la fois à un intranet et à plusieurs extranets. En général, lorsque ce document utilise le terme « VPN », il ne fait pas de distinction entre intranet et extranet.
Nous appelons le propriétaire d'un site le « client » (customer), et le propriétaire ou l'exploitant du réseau dorsal le « fournisseur de services » (Service Provider, ou SP). Le client achète au SP un « service VPN » (VPN service).
Un client peut être une entreprise unique, un groupe d'entreprises, un fournisseur d'accès Internet, un fournisseur de services applicatifs, ou un autre SP offrant à ses propres clients un service VPN similaire, etc.
La politique qui détermine si un ensemble de sites constitue un VPN appartient au client. Certains clients souhaitent que cette politique soit entièrement mise en œuvre par le SP ; d'autres peuvent souhaiter partager cette responsabilité avec le SP. Ce document spécifie des mécanismes permettant de mettre en œuvre de telles politiques. Les mécanismes décrits sont suffisamment généraux pour être pris en charge aussi bien par le SP seul que par la collaboration du client VPN et du SP ; toutefois, l'accent est principalement mis sur le premier cas.
Les mécanismes discutés ici permettent de mettre en œuvre un large éventail de politiques. Par exemple, au sein d'un VPN donné, on peut autoriser chaque site à avoir une route directe vers chaque autre site (« maillage complet », full mesh), ou forcer le trafic (traffic) entre certaines paires de sites à passer par un troisième site. Cela est utile, par exemple, si l'on souhaite que le trafic entre une paire de sites passe par un pare-feu (firewall) situé sur un troisième site.
Dans ce document, nous limitons notre discussion au cas où le client achète explicitement un service VPN auprès d'un SP, ou d'un groupe de SP s'étant entendus pour fournir le service VPN. Autrement dit, le client n'achète pas simplement un accès Internet (Internet access) au SP, et le trafic VPN ne traverse pas un ensemble de réseaux (networks) de SP interconnectés au hasard.
Nous limitons également notre discussion au cas où le réseau dorsal offre au client un service IP (plutôt qu'un service de couche 2 — layer 2 — comme le relais de trames (Frame Relay), l'ATM (Asynchronous Transfer Mode), l'Ethernet, le HDLC (High Level Data Link Control) ou le PPP (Point-to-Point Protocol)). Le client peut utiliser l'un de ces services (ou d'autres) pour se connecter au réseau dorsal, mais ce service de couche 2 se termine à la « périphérie » (edge) du réseau dorsal, où les datagrammes IP du client sont extraits de toute encapsulation (encapsulation) de couche 2.
Dans le reste de cette introduction, nous énonçons d'abord certaines propriétés que les VPN devraient présenter ; le reste du document spécifie un ensemble de mécanismes déployables pour fournir un modèle (model) de VPN possédant toutes ces propriétés. Cette section introduit également certains termes techniques utilisés dans le reste du document.
1.2. Bordure client et bordure fournisseur (Customer Edge and Provider Edge)
Les routeurs (router) peuvent être connectés entre eux, ou à des systèmes terminaux (end system), de diverses manières : connexion PPP, circuit virtuel (Virtual Circuit, ou VC) ATM, VC relais de trames, interface Ethernet, VLAN (Virtual Local Area Network) sur interface Ethernet, tunnel GRE, tunnel L2TP (Layer 2 Tunneling Protocol), tunnel IPsec, etc. Nous utiliserons le terme « circuit de raccordement » (attachment circuit) pour désigner de manière générale un tel moyen de connexion à un routeur. Un circuit de raccordement peut être une connexion généralement vue comme une « liaison de données » (data link), ou un tunnel ; l'essentiel est que deux équipements puissent devenir des pairs (peer) de couche réseau (network layer) via ce circuit.
Chaque site VPN doit contenir un ou plusieurs équipements (device) de bordure client (Customer Edge, ou CE). Chaque équipement CE est connecté via un circuit de raccordement à un ou plusieurs routeurs PE.
Les routeurs du réseau SP non connectés à un équipement CE sont appelés routeurs P (P router).
Un équipement CE peut être un hôte (host) ou un routeur. Dans le cas typique, un site contient plusieurs routeurs, dont certains sont connectés à des routeurs PE. Le routeur de site connecté à un routeur PE est l'équipement CE, ou « routeur CE ». Rien n'empêche toutefois un hôte n'assurant pas de routage d'être directement connecté à un routeur PE — dans ce cas, cet hôte est un équipement CE.
Parfois, c'est un commutateur de couche 2 (layer 2 switch) qui est physiquement connecté au routeur PE. Dans ce cas, nous ne qualifions pas ce commutateur de couche 2 d'équipement CE ; au contraire, l'équipement CE est l'hôte et les routeurs qui communiquent avec le routeur PE via ce commutateur de couche 2, l'infrastructure (infrastructure) de couche 2 étant transparente. Si l'infrastructure de couche 2 offre un service multipoint (multipoint), plusieurs équipements CE peuvent être connectés au routeur PE via le même circuit de raccordement.
Les équipements CE appartiennent logiquement au VPN du client ; les routeurs PE et P appartiennent logiquement au réseau du SP.
Le circuit de raccordement emprunté par un paquet du CE vers le PE est appelé le « circuit de raccordement d'entrée » (ingress attachment circuit) de ce paquet, et ce PE est le « PE d'entrée » (ingress PE) ; le circuit emprunté du PE vers le CE est le « circuit de raccordement de sortie » (egress attachment circuit), et ce PE est le « PE de sortie » (egress PE).
Si un routeur PE est connecté à un équipement CE dans un site d'un VPN donné, nous disons que ce routeur PE est « connecté à ce VPN particulier » ; de même, si un routeur PE est connecté à un équipement CE dans un site donné, nous disons qu'il est « connecté à ce site particulier ».
Lorsqu'un équipement CE est un routeur, il est le pair de routage des PE (ou du PE) auxquels il est connecté, mais pas des routeurs CE des autres sites. Les routeurs de sites différents n'échangent pas directement d'informations de routage (routing information) entre eux ; en fait, ils n'ont même pas besoin de se connaître mutuellement. Le client n'a donc pas de réseau dorsal ni de « réseau dorsal virtuel » (virtual backbone) à gérer, et n'a pas à traiter de routage inter-sites (inter-site routing). En d'autres termes, dans l'approche décrite ici, le VPN n'est pas une « superposition » (overlay) au-dessus du réseau SP.
En ce qui concerne la gestion des équipements de périphérie, il existe une frontière de gestion claire entre le SP et son client. Le client n'a pas besoin d'accéder aux routeurs PE ou P à des fins de gestion, et le SP n'a pas besoin d'accéder aux équipements CE à des fins de gestion.
1.3. VPN avec espaces d'adressage chevauchants (VPNs with Overlapping Address Spaces)
Si deux VPN n'ont aucun site en commun, ils peuvent avoir des espaces d'adressage (address space) qui se chevauchent. C'est-à-dire qu'une adresse donnée peut servir d'adresse au système (system) S1 dans le VPN V1, et à un système S2 totalement différent dans le VPN V2. C'est courant lorsque chaque VPN utilise l'espace d'adressage privé (private address space) de la RFC 1918. Bien sûr, au sein de chaque VPN, chaque adresse doit être sans ambiguïté.
Même si deux VPN ont un site commun, ils peuvent avoir des espaces d'adressage qui se chevauchent, tant qu'aucune communication n'est requise entre les systèmes possédant de telles adresses et les systèmes du site commun.
1.4. VPN avec routes différentes vers un même système (VPNs with Different Routes to the Same System)
Bien qu'un site puisse appartenir à plusieurs VPN, la route vers un système donné de ce site n'est pas nécessairement la même dans tous les VPN. Par exemple, supposons un intranet composé des sites A, B, C, et un extranet composé de A, B, C et d'un site « étranger » (foreign) D. Supposons qu'un serveur (server) sur le site A soit destiné à être utilisé par des clients (client) de B, C ou D. Supposons également qu'un pare-feu soit présent sur le site B. Nous souhaitons que tout le trafic de D vers ce serveur passe par ce pare-feu, afin de contrôler l'accès pour le trafic provenant de l'extranet. Mais nous ne voulons pas que le trafic de C vers ce serveur passe par le pare-feu, car il s'agit de trafic d'intranet.
On peut configurer deux routes pour ce serveur. Une route est utilisée par les sites B et C, dirigeant le trafic directement vers le site A ; la seconde route est utilisée par le site D, dirigeant plutôt le trafic vers le pare-feu du site B. Si le pare-feu autorise le trafic, celui-ci apparaît alors comme provenant du site B et est acheminé le long de la route vers le site A.
1.5. Routeurs de réseau dorsal SP (SP Backbone Routers)
Le réseau dorsal du SP est composé des routeurs PE et d'autres routeurs non connectés à des équipements CE (les « routeurs P »).
Si chaque routeur du réseau dorsal SP devait maintenir les informations de routage (routing information) de tous les VPN pris en charge par le SP, un grave problème d'évolutivité (scalability) apparaîtrait — le nombre de sites pris en charge serait limité par la quantité d'informations de routage qu'un seul routeur peut stocker. Par conséquent, l'essentiel est que les informations de routage relatives à un VPN donné n'existent que dans les routeurs PE connectés à ce VPN. En particulier, les routeurs P n'ont absolument aucun besoin d'informations de routage « par VPN ». (Cette condition devra peut-être être assouplie pour le routage multidiffusion (multicast routing) ; cela n'est pas discuté plus avant ici, mais [VPN-MCAST] le traite.)
Ainsi, tout comme le propriétaire d'un VPN n'a pas de réseau dorsal ni de « réseau dorsal virtuel » à gérer, le SP lui-même n'a pas besoin de gérer un réseau dorsal séparé ou un « réseau dorsal virtuel » pour chaque VPN. Le routage inter-sites au sein du réseau dorsal est optimal (dans les limites des politiques utilisées pour construire le VPN), et n'est contraint par aucune « topologie virtuelle » (virtual topology) de tunnel artificielle.
La section 10 traite de certains problèmes particuliers qui surviennent lorsque le réseau dorsal s'étend sur plusieurs fournisseurs de services.
1.6. Sécurité (Security)
Les VPN de ce type sont conçus pour offrir un niveau de sécurité comparable à celui obtenu avec un réseau dorsal de couche 2 (tel que le relais de trames), même sans mesure de chiffrement de sécurité. Autrement dit, en l'absence de mauvaise configuration ou de connexion délibérée de VPN différents, un système d'un VPN ne peut pas accéder à un système d'un autre VPN. Bien sûr, la méthode décrite ici ne chiffre pas les données pour les protéger, et ne fournit aucun moyen de détecter si les données ont été altérées en transit. Si ces capacités sont nécessaires, des mesures de chiffrement doivent être appliquées séparément. (Voir par exemple [MPLS/BGP-IPsec].) La section 13 discute la sécurité plus en détail.