13. Security Considerations (Considérations de sécurité)

13.1. Data Plane (Plan de données)

Par sécurité dans le "plan de données", nous entendons la protection contre les possibilités suivantes :

Des paquets provenant de l'intérieur d'un VPN sont transférés vers un site hors du VPN, mais d'une manière qui n'est pas conforme aux politiques du VPN.
Des paquets provenant de l'extérieur d'un VPN entrent dans un site du VPN, mais d'une manière qui n'est pas conforme aux politiques du VPN.

Sous les conditions suivantes :

les routeurs du réseau dorsal n'acceptent pas de paquets étiquetés via une liaison de données particulière à moins qu'il ne soit connu que cette liaison de données se connecte uniquement à un système de confiance, ou à moins qu'il ne soit connu que de tels paquets quitteront le réseau dorsal avant que l'en-tête IP ou toute étiquette inférieure de la pile ne soit inspectée, et
les routes VPN-IPv4 étiquetées ne sont pas acceptées de pairs de routage non fiables,
le plan de contrôle n'a pas été compromis par une attaque réussie,

cette architecture fournit une sécurité du plan de données pratiquement identique à celle fournie aux VPN par les réseaux dorsaux Frame Relay ou ATM. Si l'équipement sous le contrôle du SP est correctement configuré, les données n'entreront ni ne sortiront d'un VPN à moins qu'elles ne soient autorisées à le faire.

La condition 1 ci-dessus peut être énoncée plus précisément. Les paquets étiquetés reçus d'un voisin particulier doivent être rejetés à moins que l'une des deux conditions suivantes ne soit vraie :

l'étiquette supérieure du paquet a une valeur d'étiquette que le système récepteur a distribuée à ce voisin, ou
l'étiquette supérieure du paquet a une valeur d'étiquette que le système récepteur a distribuée à un système au-delà de ce voisin (c'est-à-dire, lorsqu'il est connu que le chemin du système auquel l'étiquette a été distribuée vers le système récepteur peut passer par ce voisin).

La condition 2 ci-dessus est particulièrement préoccupante dans le cas des VPN inter-fournisseurs (voir section 10). Pour les VPN inter-fournisseurs construits selon le schéma (b) de la section 10, la condition 2 est facile à vérifier. (Les problèmes de sécurité lors de l'utilisation du schéma (c) de la section 10 sont sujets à étude plus approfondie.)

Il convient de noter que l'utilisation de MPLS rend la fourniture de la sécurité du plan de données beaucoup plus simple que d'essayer d'utiliser une forme de tunneling IP à la place de l'étiquette externe MPLS. Il est très simple pour un routeur de bordure de refuser d'accepter des paquets étiquetés à moins que la première condition ci-dessus ne s'applique à lui. Il est beaucoup plus difficile de configurer un routeur pour refuser d'accepter des paquets IP s'il s'agit de paquets de tunnel IP dont la destination est un routeur PE ; ce n'est certainement pas impossible à faire, mais cela a des implications à la fois administratives et de performance.

Les tunnels MPLS-in-IP et MPLS-in-GRE sont spécifiés dans [MPLS-in-IP-GRE]. Si l'un de ces types de tunnel est souhaité pour transporter des paquets VPN, alors les considérations de sécurité décrites à la section 8 de ce document doivent être pleinement comprises. Toute implémentation de VPN IP BGP/MPLS qui permet aux paquets VPN d'être tunnelisés comme décrit dans ce document DOIT (MUST) contenir une implémentation d'IPsec destinée à être utilisée comme décrit dans celui-ci. Si le tunnel n'est pas sécurisé par IPsec, alors les techniques de filtrage d'adresse IP aux routeurs de bordure décrites à la section 8.2 de ce document sont le seul moyen de garantir qu'un paquet sortant d'un tunnel à un PE de sortie particulier a effectivement été placé dans le tunnel par le nœud de tête de tunnel correct (c'est-à-dire que le paquet n'a pas une adresse source usurpée). Comme les routeurs de bordure filtrent souvent uniquement sur l'adresse source, à moins que le PE de sortie ne puisse inspecter l'adresse source IP de tous les paquets de tunnel qu'il reçoit et la comparer à une liste d'adresses IP qui sont des adresses de tête de tunnel valides, le filtrage de paquets peut être inefficace. Toute implémentation qui permet l'utilisation de tunnels MPLS-in-IP et/ou MPLS-in-GRE sans IPsec DOIT (MUST) permettre au PE de sortie de valider l'adresse source IP de tout paquet de tunnel qu'il reçoit de cette manière.

Si plusieurs routeurs CE sont connectés à un routeur PE via une interface LAN, pour assurer une sécurité adéquate, l'une des conditions suivantes doit être vraie :

tous les routeurs CE sur le LAN appartiennent au même VPN, ou
un commutateur LAN de confiance et sécurisé partitionne le LAN en plusieurs VLAN, de sorte que chaque VLAN ne contient que des systèmes d'un seul VPN ; dans ce cas, le commutateur attachera l'étiquette VLAN appropriée à tout paquet avant de le transférer au routeur PE.

Cette architecture ne fournit pas de confidentialité cryptographique, pas plus que les VPN Frame Relay ou ATM. Toutes ces architectures sont compatibles avec l'utilisation du chiffrement basé sur CE-CE si cela est souhaité.

L'utilisation du chiffrement basé sur PE-PE fait l'objet d'une étude plus approfondie.

13.2. Control Plane (Plan de contrôle)

La sécurité du plan de données de la section précédente dépend de la sécurité du plan de contrôle. Pour assurer la sécurité, aucune connexion BGP ou LDP ne devrait être établie avec des pairs non fiables. Les deux protocoles devraient utiliser l'option d'authentification TCP/IP MD5 [TCP-MD5]. Les protocoles de routage au sein du réseau SP devraient être sécurisés de manière similaire.

13.3. Security of P and PE Devices (Sécurité des périphériques P et PE)

Si la sécurité physique de ces appareils est compromise, la sécurité du plan de données peut également être compromise.

Les mesures habituelles devraient être prises pour s'assurer que le trafic IP provenant de l'Internet public ne peut pas être utilisé pour modifier la configuration de ces appareils, ou pour lancer une attaque par déni de service (Denial of Service) contre eux.