1. Introduction (Introduction)

Ce document décrit une méthode par laquelle un fournisseur de services peut utiliser un réseau dorsal IP pour fournir des réseaux privés virtuels (Virtual Private Networks, VPN) IP à ses clients. Cette méthode utilise un "modèle d'appairage", dans lequel le routeur de périphérie du client (routeur CE) envoie ses routes au routeur de périphérie du fournisseur de services (routeur PE). Le protocole Border Gateway Protocol (BGP) [BGP, BGP-MP] est ensuite utilisé par le fournisseur de services pour échanger les routes d'un VPN particulier entre les routeurs PE qui sont attachés à ce VPN. Cela est fait de manière à garantir que les routes de différents VPN restent distinctes et séparées, même si deux VPN ont un espace d'adressage qui se chevauche. Les routeurs PE distribuent les routes d'autres routeurs CE dans un VPN particulier aux routeurs CE de ce VPN. Les routeurs CE ne s'appairent pas entre eux, il n'y a donc pas de "superposition" visible pour l'algorithme de routage du VPN. Le terme "IP" dans "IP VPN" est utilisé pour indiquer que le PE reçoit des datagrammes IP du CE, examine leurs en-têtes IP et les achemine en conséquence.

Chaque route au sein d'un VPN se voit attribuer une étiquette Multiprotocol Label Switching (MPLS) [MPLS-ARCH, MPLS-BGP, MPLS-ENCAPS] ; lorsque BGP distribue une route VPN, il distribue également une étiquette MPLS pour cette route. Avant qu'un paquet de données client ne traverse le réseau dorsal du fournisseur de services, il est encapsulé avec l'étiquette MPLS qui correspond à la route du VPN du client correspondant le mieux à l'adresse de destination du paquet. Ce paquet MPLS est ensuite encapsulé (par exemple, avec une autre étiquette MPLS, ou avec un en-tête IP ou Generic Routing Encapsulation (GRE) [MPLS-in-IP-GRE]) afin qu'il puisse être tunnelisé à travers le réseau dorsal jusqu'au routeur PE approprié. Ainsi, les routeurs centraux du réseau dorsal n'ont pas besoin de connaître les routes VPN.

L'objectif principal de cette méthode est de soutenir le cas où le client obtient des services 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 de services Internet, un fournisseur de services d'application, un autre fournisseur de services VPN utilisant la même méthode pour fournir des VPN à ses propres clients, etc. Cette méthode rend l'utilisation des services de réseau dorsal très simple pour le client. Elle est également très évolutive et flexible pour le fournisseur de services, et permet au fournisseur de services d'ajouter de la valeur.

1.1. Virtual Private Networks (Réseaux privés virtuels)

Considérons un ensemble de "sites" attachés à un réseau commun, que nous appelons le "réseau dorsal". Appliquons maintenant certaines politiques pour créer un certain nombre de sous-ensembles de cette collection, et imposons la règle suivante : deux sites peuvent avoir une connectivité IP via ce réseau dorsal si et seulement s'ils sont tous les deux contenus dans au moins un de ces sous-ensembles.

Ces sous-ensembles sont des réseaux privés virtuels (VPN). Deux sites ont une connectivité IP sur le réseau dorsal commun uniquement s'il existe un VPN qui contient les deux sites. Deux sites qui n'ont pas de VPN en commun n'ont pas de connectivité sur ce réseau dorsal.

Si tous les sites d'un VPN appartiennent à la même entreprise, le VPN peut être considéré comme "l'intranet" de l'entreprise. Si les différents sites d'un VPN appartiennent à des entreprises différentes, le VPN peut être considéré comme un "extranet". Un site peut être dans plus d'un VPN ; par exemple, dans un intranet et plusieurs extranets. En général, lorsque nous utilisons le terme "VPN", nous ne ferons pas de distinction entre les intranets et les extranets.

Nous appelons le propriétaire des sites le "client". Nous appelons le propriétaire/opérateur du réseau dorsal le "fournisseur de services" (SP). Le client obtient un "service VPN" auprès du SP.

Le client peut être une entreprise unique, un groupe d'entreprises, un fournisseur de services Internet, un fournisseur de services d'application, un autre SP offrant le même type de service VPN à ses propres clients, etc.

Les politiques qui déterminent si une collection particulière de sites est un VPN sont les politiques du client. Certains clients souhaitent que le SP soit entièrement responsable de la mise en œuvre de ces politiques. D'autres clients peuvent souhaiter partager la responsabilité de la mise en œuvre de ces politiques avec le SP. Ce document spécifie les mécanismes qui peuvent être utilisés pour mettre en œuvre ces politiques. Les mécanismes que nous décrivons sont suffisamment généraux pour permettre la mise en œuvre de ces politiques soit par le SP seul, soit conjointement par le client VPN et le SP. La plupart de la discussion se concentre toutefois sur le premier cas.

Les mécanismes discutés dans ce document permettent la mise en œuvre d'un large éventail de politiques. Par exemple, au sein d'un VPN donné, il peut être permis à chaque site d'avoir une route directe vers tous les autres sites ("maillage complet"). Alternativement, il peut être forcé que le trafic entre certaines paires de sites soit acheminé via un troisième site. Cela peut être utile, par exemple, s'il est souhaité que le trafic entre une paire de sites passe par un pare-feu, et que le pare-feu est situé sur le troisième site.

Dans ce document, nous restreignons la discussion au cas où le client achète explicitement un service VPN auprès d'un SP, ou d'un ensemble de SP qui ont convenu de coopérer pour fournir le service VPN. Autrement dit, le client n'achète pas simplement un accès Internet auprès d'un SP, et le trafic VPN ne passe pas par une collection aléatoire de réseaux SP interconnectés.

Nous restreignons également la discussion au cas où le réseau dorsal fournit un service IP au client, plutôt que de fournir un service de couche 2 tel que Frame Relay, Asynchronous Transfer Mode (ATM), Ethernet, High Level Data Link Control (HDLC), ou Point-to-Point Protocol (PPP). Le client peut se connecter au réseau dorsal via l'un de ces services de couche 2 (ou d'autres), mais le service de couche 2 se termine au "bord" du réseau dorsal, où les datagrammes IP du client sont retirés de toute encapsulation de couche 2.

Dans le reste de cette introduction, nous spécifions certaines propriétés que les VPN devraient posséder. Le reste du document spécifie un ensemble de mécanismes qui peuvent être déployés pour fournir un modèle de VPN qui possède toutes ces propriétés. Cette section introduit également une terminologie technique utilisée dans le reste du document.

1.2. Customer Edge and Provider Edge (Périphérique client et périphérique fournisseur)

Les routeurs peuvent être connectés les uns aux autres, ou à des systèmes terminaux, de différentes manières : connexions PPP, circuits virtuels (VC) ATM, VC Frame Relay, interfaces Ethernet, Virtual Local Area Networks (VLAN) sur interfaces Ethernet, tunnels GRE, tunnels Layer 2 Tunneling Protocol (L2TP), tunnels IPsec, etc. Nous utiliserons le terme "circuit d'attachement" pour désigner un moyen quelconque d'attachement à un routeur. Un circuit d'attachement peut être le type de connexion qui est généralement considéré comme une "liaison de données", ou il peut s'agir d'un tunnel quelconque ; ce qui compte, c'est que deux appareils puissent être des pairs de couche réseau via le circuit d'attachement.

Chaque site VPN doit contenir un ou plusieurs appareils Customer Edge (CE). Chaque appareil CE est attaché, via un certain type de circuit d'attachement, à un ou plusieurs routeurs Provider Edge (PE).

Les routeurs du réseau SP qui ne sont pas attachés à des appareils CE sont appelés "routeurs P".

Les appareils CE peuvent être des hôtes ou des routeurs. Dans le cas typique, un site contient un ou plusieurs routeurs, dont certains sont attachés à des routeurs PE. Les routeurs du site qui se connectent aux routeurs PE sont les appareils CE, ou "routeurs CE". Cependant, rien n'empêche un hôte non routeur de se connecter directement à un routeur PE. Dans ce cas, cet hôte est un appareil CE.

Parfois, ce qui est physiquement attaché à un routeur PE est un commutateur de couche 2. Dans ce cas, nous ne disons pas que le commutateur de couche 2 est un appareil CE. Au contraire, les appareils CE sont les hôtes et les routeurs qui communiquent avec le routeur PE via le commutateur de couche 2 ; l'infrastructure de couche 2 est transparente. Si l'infrastructure de couche 2 fournit un service multipoint, alors plusieurs appareils CE peuvent être attachés au routeur PE via le même circuit d'attachement.

Les appareils CE font logiquement partie du VPN du client. Les routeurs PE et P font logiquement partie du réseau SP.

Le circuit d'attachement sur lequel un paquet voyage lorsqu'il va du CE au PE est connu comme le "circuit d'attachement entrant" de ce paquet, et ce PE est connu comme le "PE entrant" du paquet. Le circuit d'attachement sur lequel un paquet voyage lorsqu'il va du PE au CE est connu comme le "circuit d'attachement sortant" de ce paquet, et ce PE est connu comme le "PE sortant" du paquet.

Si un routeur PE est attaché à un appareil CE qui appartient à un site VPN particulier, nous dirons que ce routeur PE est attaché à ce VPN. De même, si un routeur PE est attaché à un appareil CE appartenant à un site particulier, nous dirons que ce routeur PE est attaché à ce site.

Lorsque l'appareil CE est un routeur, il est un pair de routage du PE auquel il est attaché, mais il n'est pas un pair de routage des routeurs CE d'autres sites. Les routeurs de différents sites n'échangent pas directement d'informations de routage entre eux ; en fait, ils n'ont même pas besoin de se connaître. Ainsi, le client n'a pas de réseau dorsal ou de "réseau dorsal virtuel" à gérer, et n'a pas à traiter les problèmes de routage inter-sites. En d'autres termes, dans le schéma décrit dans ce document, un VPN n'est pas une "superposition" au-dessus du réseau SP.

En ce qui concerne la gestion des appareils de périphérie, une limite de gestion claire est maintenue 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 appareils CE à des fins de gestion.

1.3. VPNs with Overlapping Address Spaces (VPN avec espaces d'adressage chevauchants)

Si deux VPN n'ont pas de sites en commun, alors ils peuvent avoir des espaces d'adressage qui se chevauchent. C'est-à-dire qu'une adresse donnée peut être utilisée dans le VPN V1 comme adresse du système S1, mais dans le VPN V2 comme adresse d'un système complètement différent S2. C'est une situation courante lorsque chaque VPN utilise l'espace d'adressage privé RFC 1918. Bien sûr, au sein de chaque VPN, chaque adresse doit être sans ambiguïté.

Même deux VPN qui ont des sites en commun peuvent avoir des espaces d'adressage qui se chevauchent, tant qu'il n'est pas nécessaire que des systèmes possédant de telles adresses communiquent avec des systèmes dans les sites communs.

1.4. VPNs with Different Routes to the Same System (VPN avec des routes différentes vers le même système)

Bien qu'un site puisse être dans plusieurs VPN, il n'est pas nécessaire que la route vers un système donné sur ce site soit la même dans tous les VPN. Supposons par exemple que nous ayons un intranet composé des sites A, B et C, et un extranet composé de A, B, C et d'un site "externe" D. Supposons qu'il y ait un serveur sur le site A que nous voulons rendre accessible aux clients de B, C ou D. Supposons également qu'il y ait un pare-feu sur le site B. Nous voulons que tout le trafic du site D vers le serveur passe par le pare-feu, afin que le contrôle d'accès puisse être appliqué au trafic de l'extranet. Cependant, nous ne voulons pas que le trafic de C passe par le pare-feu en route vers le serveur, car il s'agit de trafic intranet.

Deux routes vers le serveur peuvent être établies. Une route est utilisée par les sites B et C, et amène le trafic directement au site A. La deuxième route est utilisée par le site D, et amène le trafic au pare-feu du site B. Si le pare-feu laisse passer le trafic, il ressemble alors à du trafic provenant du site B et suit la route vers le site A.

1.5. SP Backbone Routers (Routeurs dorsaux du SP)

Le réseau dorsal du SP se compose des routeurs PE ainsi que d'autres routeurs ("routeurs P") qui ne sont pas attachés aux appareils CE.

Si chaque routeur dans le réseau dorsal du SP devait conserver des informations de routage pour tous les VPN supportés par le SP, il y aurait de graves problèmes d'évolutivité ; le nombre de sites pouvant être supportés serait limité par la quantité d'informations de routage qu'un seul routeur pourrait contenir. Par conséquent, il est important que les informations de routage concernant un VPN particulier n'aient besoin d'être présentes que dans les routeurs PE qui sont attachés à ce VPN. En particulier, les routeurs P ne devraient avoir besoin d'avoir aucune information de routage par VPN. (Lors de l'examen du routage multicast, cette condition peut devoir être légèrement assouplie. Cela n'est pas discuté davantage ici, mais est examiné dans [VPN-MCAST].)

Ainsi, tout comme les propriétaires de VPN n'ont pas de réseau dorsal ou de "réseau dorsal virtuel" à gérer, le SP lui-même ne gère pas un réseau dorsal ou "réseau dorsal virtuel" distinct pour chaque VPN. Le routage inter-sites dans le réseau dorsal est optimal (dans les contraintes des politiques utilisées pour former les VPN) et n'est pas contraint par une quelconque "topologie virtuelle" artificielle de tunnels.

La section 10 discute de certains problèmes spéciaux qui surviennent lorsque le réseau dorsal s'étend sur plusieurs fournisseurs de services.

1.6. Security (Sécurité)

Les VPN de ce type, tels que discutés ici, sont destinés à fournir un niveau de sécurité équivalent à celui pouvant être obtenu lors de l'utilisation d'un réseau dorsal de couche 2 (par exemple, Frame Relay), même si aucune mesure de sécurité cryptographique n'est utilisée. C'est-à-dire qu'en l'absence de mauvaise configuration ou d'interconnexion délibérée de différents VPN, il est impossible pour un système dans un VPN d'accéder à un système dans un autre VPN. Bien sûr, les méthodes décrites ici ne chiffrent pas les données pour la confidentialité, ni ne fournissent un moyen de déterminer si les données ont été altérées en transit. Si ces fonctionnalités sont souhaitées, des mesures cryptographiques doivent être appliquées en plus (voir, par exemple, [MPLS/BGP-IPsec]). La sécurité est discutée plus en détail dans la section 13.