Retrouvez cet article dans : Misc 20

L’une des problématiques récurrentes des réseaux est de faire transiter des données le plus rapidement et le plus sûrement possible. La disponibilité des services réseau est généralement couverte par la topologie du réseau. Quant à l’intégrité des services réseau, elle est généralement couverte par les protocoles réseau.
Dans les réseaux IP, le routage des paquets s’effectue sur les adresses IP (Internet Protocol), ce qui nécessite de lire les en-têtes IP à chaque passage sur un nœud réseau. Pour réduire ce temps de lecture, deux protocoles ont vu le jour afin d’améliorer le transit global par une commutation des paquets au niveau 2 et non plus 3, comme le fait IP.

1. Introduction

Plutôt que de décider du routage des paquets dans le réseau à partir des adresses IP, le protocole MPLS (Multi Protocol Label Switching) s’appuie sur des labels. La commutation de paquets se réalise donc sur ces labels et ne consulte plus les informations relatives au niveau 3 incluant les adresses IP. En d’autres termes, l’acheminement ou la commutation des paquets est fondée sur les labels et non plus sur les adresses IP [RFC3270] :

Même si l’amélioration des équipements hardware ne rend plus aussi nécessaire qu’auparavant la commutation au niveau 2 plutôt qu’au niveau 3, le protocole MPLS présente des avantages notables par rapport au protocole IP. De plus, des classes de services peuvent être définies afin de garantir les délais d’acheminement.

2. Création d'un réseau privé virtuel MPLS/VPN

Un réseau privé virtuel MPLS/VPN permet de connecter des sites distants sur un réseau partagé par tous les clients. Le trafic du réseau privé virtuel est isolé logiquement des autres trafics VPN. Cette isolation est réalisée par un mécanisme de routage fondé sur le protocole MP-BGP, qui est une extension du protocole de routage BGP (Border Gateway Protocol) pour les réseaux MPLS [RFC2547]. Le protocole MP-BGP fonctionne en collaboration avec un protocole de distribution de labels (Label Distribution Protocol) afin d'associer un label à une route externe. Dans ce cas, deux niveaux de labels sont utilisés, le premier label correspond à la route dans le VPN concerné et le second label correspond au PE permettant d'atteindre le prochain saut BGP.
De plus, chaque VPN peut faire transiter les classes d’adresses IP qu’il désire sans qu’il y ait de conflit d’adresses IP avec d’autres VPN. Chaque VPN a en effet sa propre table de routage et la commutation du trafic réseau est réalisée sur des labels uniques et non sur des adresses IP. Pour cela, un identifiant appelé RD (Route Distinguisher) est accolé à chaque subnet IPv4 afin de créer une route VPNv4. En revanche, dans le cas d'un Extranet ou d'un accès à un fournisseur de services, les adresses IP devront être uniques afin de partager les ressources communes.
Un réseau MPLS/VPN est composé de routeurs P (Provider : dédiés à la commutation), de routeurs PE (Provider Edge : dédiés à la création des MPLS/VPN ainsi qu’à la connectivité avec les équipements localisés chez les clients) et de routeurs CE (Customer Edge : installés chez les clients et connectés aux routeurs PE). Seuls les routeurs PE contiennent la définition des MPLS/VPN, les routeurs P et CE n’ayant aucune connaissance de la configuration des MPLS/VPN. Les routeurs P commutent des labels, tandis que les routeurs CE commutent des adresses IP. La sécurité logique d’un MPLS/VPN repose principalement sur la configuration logique du VPN dans les configurations des routeurs PE. Pour mieux comprendre les enjeux de configuration des MPLS/VPN, prenons l’exemple de deux VPN A et B reliant deux sites différents pour chacun des VPN, comme illustré à la figure 2 ci-après :

Nous avons vu que le RD (Route Distinguisher) permet de garantir l’unicité des routes VPNv4 échangées entre les PE, mais ne définit pas la manière dont les routes vont être insérées dans les VPN. Pour y parvenir, l’import et l’export de routes sont réalisés à l’aide d'une communauté étendue de routage (extended community) appelée " Route-Target " (RT). Les routes-targets doivent être vues comme des filtres appliqués sur les routes VPNv4. Dans notre exemple, les routeurs CE1 A et CE2 A appartiennent au MPLS/VPN A et les routeurs CE1 B et CE2 B appartiennent au MPLS/VPN B.
La configuration des routeurs PE permet de créer ces VPN sur le réseau. Nous utiliserons le terme VRF (Virtual Routing Forwarding) par la suite pour désigner un VPN.
Par exemple, la configuration du routeur PE, connecté à CE1 A et CE1 B, est la suivante :

 # Définition du MPLS/VPN A :
ip vrf A

   # La valeur du rd (route distinguisher) permet d'identifier les routes échangées entre
   # les routeurs PE pour chaque MPLS/VPN
    rd 1 

    # Les valeurs des routes-targets RT permettent de définir un MPLS/VPN.  Le MPLS/VPN A n'accepte
    # que les routes reçues véhiculant le RT 1 et exporte les routes apprises en insérant le RT 1
    route-target import 1
    route-target export 1
!
Définition du MPLS/VPN B :
ip vrf B
   rd 2
   route-target import 2
   route-target export 2
!
# Connexion de CE1 A au PE : Cette connexion appartient au MPLS/VPN A
interface …
   ip vrf forwarding A
   …
!
# Connexion de CE1 B au PE : Cette connexion appartient au MPLS/VPN B
interface …
   ip vrf forwarding B
   …
!
# Description de la session de routage avec le MPLS/VPN A
address-family ipv4 vrf A
 neighbor 10.10.10.102 activate
!
# Description de la session de routage avec le MPLS/VPN B
address-family ipv4 vrf B
 neighbor 192.10.10.102 activate
!

L’isolation d’un MPLS/VPN repose donc sur les configurations des routeurs PE. Le périmètre d’un MPLS/VPN peut donc être déterminé à partir de toutes les configurations des routeurs PE constituant le réseau MPLS comme nous le détaillerons ci-après [MPLS Sécurité].

3. Analyse de la consistance de configuration des MPLS/VPN

Sachant que les inconsistances des configurations MPLS/VPN peuvent engendrer des problèmes de sécurité (isolation, intégrité, etc.), nous considérerons qu’une configuration est consistante par rapport aux MPLS/VPN si les deux conditions suivantes (ou invariants) sont remplies :

• Tous les éléments de type VRF définis/configurés dans un routeur PE doivent être référencés.
• Tous les éléments de type VRF référencés dans un routeur PE doivent être définis/configurés.

Si nous prenons la configuration CISCO conf_test suivante :

 ip vrf A
    rd 1
    route-target import 1
    route-target export 1
!
ip vrf B
   rd 2
   route-target import 2
   route-target export 2
!
interface x
   ip vrf forwarding A
!
interface y
   ip vrf forwarding B
!
address-family ipv4 vrf A
 neighbor 10.10.10.104 activate
!
address-family ipv4 vrf B
 neighbor 192.10.10.104 activate
!

Le script vpn_check.sh (http://www.miscmag.com/articles/20-MISC/conf-vpn/) vérifie la consistance d'implémentation des MPLS/VPN dans une configuration PE CISCO. Ce script, écrit en AWK, est un exemple non exhaustif et devra donc être complété. Il s’exécute sur une configuration CISCO.
Si on exécute ce script sur la configuration conf_test, on obtient alors le résultat suivant (aucune inconsistance n'a été détectée) :

bash$ awk -f ./vpn_check.sh ./conf_test
bash$

Modifions la configuration afin d'introduire des inconsistances comme l'illustre la commande UNIX diff entre les deux fichiers conf_test et conf_test1 :

bash$ diff ./conf ./conf1
6c6
< ip vrf B
---
> ip vrf D
12c12
<    ip vrf forwarding A
---
>    ip vrf forwarding C
17c17
< address-family ipv4 vrf A
---
> address-family ipv4 vrf F
22c22
< address-family ipv4 vrf B
---
> address-family ipv4 vrf E

Si on exécute ce script sur la configuration conf_test1, on obtient alors le résultat suivant pointant les inconsistances de configuration :

bash$ awk -f ./vpn_check.sh ./conf_test1
./conf_test; déf/non réf;A;ip vrf A(line 1)
./conf_test; déf/non réf;D;ip vrf D(line 6)
./conf_test; réf/non déf;B;   ip vrf forwarding B(line 15)
./conf_test; réf/non déf;C;   ip vrf forwarding C (line 12)
./conf_test; réf/non déf;E;address-family ipv4 vrf E(line 22)
./conf_test; réf/non déf;F;address-family ipv4 vrf F(line 17)
bash$

4. Calcul du périmètre de sécurité d'un MPLS/VPN

Si on désire vérifier les périmètres de configuration des réseaux privés virtuels MPLS/VPN, l'approche consiste à analyser le graphe VPN engendré par les configurations des MPLS/VPN (seules les configurations des routeurs PE nous intéressent). Nous définirons alors le périmètre de sécurité d'un MPLS/VPN, comme étant l'ensemble des interconnexions autorisées de ce VPN avec d'autres VPN.
De manière générale, si pour chaque configuration PE, on arrive à renseigner les champs de la table VPN suivante, il est alors possible de construire le graphe VPN que nous détaillerons par la suite :

 table VPN
	champ : NomVrf : nom du VPN
	champ : I/E: définit l'action associée au route-target,
               soit "import" (j'apprends les routes), soit "export" (j'exporte les routes)
	champ : RT : définit la valeur du route-target

Le calcul d'un périmètre de sécurité d'un MPLS/VPN nécessite avant tout d'avoir toutes les configurations des routeurs PE. L'idée consiste ensuite à construire pour chaque route-target, l'ensemble des VRF qui réalisent un import et l'ensemble des VRF qui réalisent un export comme l'illustre la figure 3.
On peut alors en déduire les liens de connectivité entre les VRF. Ainsi, pour une route-target donnée, chaque VRF appartenant à la liste des export est alors connectée à toutes les VRF appartenant à la liste des import. Par exemple, pour la route-target RTx, la VRF 1 est connectée à la VRF 3, et la VRF 2 est connectée à
la VRF 3.
On peut alors construire un graphe VPN, où un sommet est représenté par une VRF et un arc par une connexion entre deux VRF différentes. Prenons comme exemple les configurations des VRF suivantes :

 ip vrf A
 rd 1
 route-target export 1
 route-target import 1
 route-target export 4
 route-target import 3
!
ip vrf B
 rd 2
 route-target export 2
 route-target import 2
 route-target export 4
 route-target import 3
!
ip vrf C
 rd 3
 route-target export 3
 route-target import 4
!
ip vrf D
 rd 4
 route-target export 5
 route-target import 5
!

Le script vpn_extract.sh (http://www.miscmag.com/articles/20-MISC/conf-vpn/) permet de renseigner la table VPN. Il constitue un exemple non exhaustif et devra donc être complété.
Si on exécute ce script sur cette configuration, on obtient alors le résultat suivant :

 bash$ awk -f ./vpn_extract.sh ./conf_test
A export 1
A import 1
A export 4
A import 3
B export 2
B import 2
B export 4
B import 3
C export 3
C import 4
D export 5
D import 5
bash$

Une fois la table VPN construite à partir de l'extraction des informations contenues dans les configurations, le produit cartésien de la table VPN par elle-même sous les conditions suivantes donne alors tous les arcs de notre graphe VPN, comme l'illustre la requête SQL suivante :

SELECT
	    Vpn.NomVrf, Vpn.I/E, Vpn.Rt, Vpn_1.NomVrf, Vpn_1.I/E, Vpn_1.Rt
FROM
  	    Vpn, Vpn AS Vpn_1
WHERE
 	     Vpn.Rt = Vpn_1.Rt and
         Vpn.IE = "export" and Vpn_1.IE = "import" and
         Vpn.NomVrf != Vpn_1.NomVrf

Un sommet du graphe VPN est donc représenté par NomVrf et un arc par un enregistrement trouvé par le produit cartésien précédemment décrit. Par ailleurs, l'asymétrie de configuration d'un VPN indique que le graphe VPN construit est dirigé. Dans notre configuration conf_test, la table VPN serait alors renseignée par les données suivantes :

Maintenant, si on réalise le produit cartésien précédemment décrit, on obtient alors les informations suivantes (en fait les routes-targets nous permettent d'établir les relations de connectivité entre les sommets) :

Les sommets du graphe VPN sont donc {A,B,C,D} et les arcs du graphe VPN sont les suivants :

A est VPN-connecté à C
B est VPN-connecté à C
C est VPN-connecté à A
C est VPN-connecté à B

Le graphe VPN associé est le suivant :

De manière générale, le calcul des composantes fortement connexes du graphe VPN (si pour toute paire de sommets
(x, y) de la  composante, il existe un chemin de x à y et de y à x) permet de déterminer les périmètres de sécurité des VPN. Dans notre cas, il y a deux composantes fortement connexes qui sont {A, B, C} et {D}. Ces composantes indiquent que le périmètre de sécurité du VPN A est {A, B, C}, que le périmètre de sécurité du VPN B est {A, B, C}, que le périmètre de sécurité du VPN C est {A, B, C} et que le périmètre de sécurité du VPN D est {D}.
De manière théorique, les composantes fortement connexes du graphe VPN donnent les périmètres de sécurité réels des VPN qui ont pu être définis dans les configurations. Ces périmètres de sécurité montrent alors soit l'isolation d'un VPN donné, soit des interconnexions avec d'autres VPN. Le calcul des points d'articulation du graphe VPN permet aussi de connaître les points de passage obligé (i. e. VPN) dans une composante fortement connexe et donne ainsi des informations topologiques de sécurité intéressantes. Rappelons que l'extraction de toutes les composantes fortement connexes d'un graphe et le calcul des points d'articulation sont des problèmes faciles [BRASSARD].
Enfin, si les composantes connexes (s’il existe un chemin entre toute paire de sommets (x, y) de la composante) du graphe VPN ne sont pas égales aux composantes fortement connexes (si pour toute paire de sommets (x, y) de la composante, il existe un chemin de x à y et de y à x) du graphe VPN, il y a alors des inconsistances de configuration des VPN. De même, toute configuration non bidirectionnelle entre deux sommets montre aussi des inconsistances de configuration des VPN.

 5. Les interconnexions des réseaux MPLS/VPN

Les opérateurs de télécommunications développent de plus en plus les services réseau MPLS/VPN et ont besoin de s'interconnecter à d'autres réseaux pour étendre un MPLS/VPN. L'interconnexion entre deux réseaux MPLS/VPN se réalise de deux manières possibles, soit sur le modèle " VRF-To-VRF ", soit sur le modèle " MP-eBGP " que nous allons décrire ci-après [CISCO, JUNIPER].

5.1. Le modèle " VRF-To-VRF "

Comme l'illustre la figure suivante, le modèle " VRF-To-VRF " permet d'interconnecter en point à point un MPLS/VPN entre deux réseaux :

Les avantages de ce modèle sont les suivants :

• Le confinement des VPN dans des tunnels dédiés en point à point. L'isolation entre les VPN interconnectés est ainsi renforcée.
• La granularité d'analyse en cas de problème réseau est fine par l'isolation de configuration des VPN.
• Il est possible de filtrer le trafic IP par VPN. On peut alors effectivement filtrer le trafic du VPN sur les adresses IP et/ou sur les ports TCP/UDP par les mécanismes classiques de filtrage des paquets (i. e. Access Control List).
• Il est possible de filtrer le routage par VPN. On peut effectivement contrôler les adresses IP routées sur le VPN par les mécanismes classiques de filtrage de route (i. e. Prefix-list). Notons qu'il est aussi possible de mettre en Å“uvre des mécanismes de contrôle de l'instabilité des mises à jour des routes (i. e. Dampening).

Les désavantages de ce modèle sont les suivants :

• Les configurations des VPN deviennent consommatrices en termes de ressources si le nombre de VPN augmente considérablement. Notons alors que le nombre des équipements d'interconnexion devra aussi augmenter entre les deux réseaux MPLS/VPN.
• L'architecture d'interconnexion devient complexe si le nombre des équipements d'interconnexion entre les deux réseaux MPLS/VPN augmente considérablement. Rappelons que cette architecture doit assurer la disponibilité réseau de l'interconnexion MPLS/VPN.

5.2. Le modèle " MP-eBGP "

Comme l'illustre la figure suivante, le modèle " MP-eBGP " permet d'interconnecter de manière globale deux réseaux MPLS/VPN :

Les avantages de ce modèle sont les suivants :

• La configuration d'un VPN est simplifiée puisqu'on ne définit plus les connexions point à point, ni même le VPN explicitement. Seuls des filtrages, configurés de manière symétrique, des routes-targets entre les deux réseaux permettent de contrôler les interconnexions des VPN.
• Le modèle est extensible même si le nombre de VPN à interconnecter devient important. Rappelons encore qu'il n'y a pas de configuration explicite de VPN à créer.
• L'architecture réseau est simplifiée et extensible, même si le nombre de VPN à interconnecter devient important. Seules les capacités de commutation des équipements d'interconnexion seront impactées.

Les désavantages de ce modèle sont les suivants :

• La granularité d'analyse en cas de problème réseau n'est plus fine et nécessite en revanche d'analyser les sessions de routage MP-eBGP.
• Il n'y a pas de possibilité de filtrer le trafic IP par VPN (dans la limite des technologies existantes). Cependant, un filtrage est possible au niveau du trafic des données de l'ensemble des VPN.
• Il n'y a pas de possibilité de filtrer le routage des adresses IP par VPN (dans la limite des technologies existantes). Cependant, un filtrage est possible au niveau des routes-targets échangées entre les deux réseaux permettant de définir les interconnexions des VPN.

Les deux modèles (VRF-To-VRF, MP-eBGP) ont leurs avantages et leurs inconvénients. Il doit être noté que non seulement les technologies et les fonctions de contrôle évoluent, mais aussi qu'une interconnexion entre deux réseaux MPLS/VPN peut être un mixte de ces deux modèles.

Conclusion
Les architectures MPLS/VPN offrent de bonnes garanties de sécurité si les conditions de contrôle sont réalisées sur les configurations des équipements réseau.
De plus, sachant qu'un MPLS/VPN n'est finalement qu'un élément de routage, le contrôle des processus de routage au sein du réseau devient critique. Ce besoin ouvre la voie des sondes d'analyse et de détection des problèmes de routage réseau IGP (Interior Gateway Protocol) ou EGP (Exterior Gateway Protocol).
Enfin, le déploiement d'architectures MPLS/VPN par les opérateurs de télécommunications s'accélère et intègre de nouvelles technologies au cœur du réseau MPLS tel que le trafic engineering, l'intégration des classes de services en périphérie et au cœur du réseau, etc.

Références

• [BRASSARD] Brassard (G.), Bratley (P.), Fundamentals of algorithmics, Prentice Hall, ASIN : 0133350681, 1995.
• [CISCO] http://www.cisco.com/warp/public/732/Tech/mpls/docs/interasconfig.ppt
• [JUNIPER] http://www.juniper.net/techpubs/software/junos/junos64/swconfig64-vpns/download/cofc-overview.pdf
• [MPLS Sécurité] CISCO : ftp://ftp-eng.cisco.com/cons/isp/security/MPLS-Security
• [RFC2547] Rosen (E.), Rekhter (Y.), BGP/MPLS VPN, INFORMATIONAL, March 1999.
• [RFC3270] Le Faucheur (F.), Wu (L.), Davie (B.), Davari (S.), Vaananen (P.), Krishnan (R.), Cheval (P.), Heinanen (J.), Multi-Protocol Label Switching (MPLS) Support of Differentiated Services, PROPOSED STANDARD, May 2002.

  Retrouvez cet article dans : Misc 20