13. Security Considerations

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

13.1. Plan de données (Data Plane)

Par « sécurité dans le plan de données » (data plane), nous entendons la protection contre les possibilités suivantes :

• Des paquets (packet) provenant de l'intérieur d'un VPN se rendent vers un site extérieur au VPN, d'une manière non conforme à la politique (policy) de ce VPN.

• Des paquets provenant de l'extérieur d'un VPN pénètrent dans un des sites du VPN, d'une manière non conforme à la politique de ce VPN.

Aux conditions suivantes :

1. un routeur de réseau dorsal (backbone router) n'accepte pas de paquets étiquetés sur une liaison de données (data link) particulière, à moins qu'il ne soit établi que cette liaison de données est raccordée uniquement à des systèmes de confiance (trusted), ou à moins qu'il ne soit établi que de tels paquets quitteront le réseau dorsal avant que l'en-tête IP ou toute étiquette plus bas dans la pile ne soit inspecté, et

2. les routes VPN-IPv4 étiquetées ne sont pas acceptées depuis des pairs de routage (routing peer) non fiables ou non sûrs,

3. aucune attaque (attack) réussie n'a été menée sur le plan de contrôle (control plane),

la sécurité du plan de données fournie par cette architecture est pratiquement identique à celle fournie aux VPN par les réseaux dorsaux relais de trames ou ATM. Si les équipements sous le contrôle du SP sont correctement configurés, les données n'entrent ni ne quittent un VPN, sauf si elles y sont autorisées.

La condition 1 ci-dessus peut être énoncée plus précisément. Il convient d'ignorer (discard) un paquet étiqueté reçu depuis un voisin (neighbor) particulier, à moins que l'une des deux conditions suivantes ne soit remplie :

• l'étiquette au sommet (top label) du paquet a une valeur d'étiquette que le système receveur a distribuée à ce voisin, ou

• l'étiquette au sommet du paquet a une valeur d'étiquette que le système receveur a distribuée à un système au-delà de ce voisin (c'est-à-dire lorsqu'il est établi que le chemin depuis le système auquel l'étiquette a été distribuée vers le système receveur peut passer par ce voisin).

La condition 2 ci-dessus présente le plus d'intérêt 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. (La question de la sécurité lorsque le schéma c) de la section 10 est utilisé est laissée pour étude ultérieure.)

Il convient de noter que l'utilisation de MPLS rend beaucoup plus simple la fourniture de la sécurité du plan de données que si l'on tentait d'utiliser une forme de tunnel IP à la place de l'étiquette externe MPLS. Il est simple de faire en sorte que les routeurs de bordure refusent d'accepter un paquet étiqueté, à moins que la première des conditions ci-dessus ne s'applique. Il est plutôt plus difficile de configurer un routeur pour refuser d'accepter un paquet IP s'il s'agit d'un paquet tunnelisé IP dont l'adresse de destination est celle d'un routeur PE ; certes, cela n'est pas impossible, mais cela a des implications tant de gestion que de performance.

Les tunnels MPLS-in-IP et MPLS-in-GRE sont spécifiés dans [MPLS-in-IP-GRE]. Si l'on souhaite utiliser de tels tunnels 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 autorisant des paquets VPN à être tunnelisés comme décrit dans ce document DOIT contenir une implémentation IPsec utilisable comme indiqué. Si le tunnel n'est pas sécurisé par IPsec, alors la technique de filtrage d'adresses IP aux routeurs de bordure, décrite à la section 8.2 de ce document, est le seul moyen de garantir qu'un paquet qui émerge du tunnel à un PE de sortie particulier a bien été placé dans le tunnel par le nœud de tête de tunnel approprié (c'est-à-dire que le paquet n'a pas d'adresse source usurpée — spoofed source address). Étant donné que les routeurs de bordure filtrent fréquemment uniquement les adresses source, le filtrage de paquets peut ne pas être efficace à moins que le PE de sortie ne puisse vérifier l'adresse source IP de tout paquet tunnelisé qu'il reçoit, et la comparer à une liste d'adresses IP valides comme têtes de tunnel. Toute implémentation autorisant l'utilisation de tunnels MPLS-in-IP et/ou MPLS-in-GRE sans IPsec DOIT permettre au PE de sortie de valider de cette manière l'adresse source IP de tout paquet tunnelisé qu'il reçoit.

Dans le cas où plusieurs routeurs CE sont raccordés à un routeur PE via une interface LAN, pour garantir une sécurité appropriée, l'une des deux conditions suivantes doit être remplie :

1. Tous les routeurs CE sur le LAN appartiennent au même VPN, ou

2. Un commutateur LAN de confiance et sécurisé divise le LAN en plusieurs VLAN, chaque VLAN ne contenant que les systèmes d'un seul VPN ; dans ce cas, le commutateur attachera la balise (tag) VLAN appropriée à tout paquet avant de le transférer vers le routeur PE.

La confidentialité cryptographique (cryptographic privacy) n'est fournie ni par cette architecture, ni par les VPN relais de trames ou ATM. Ces architectures sont toutes compatibles avec l'utilisation de la cryptographie (cryptography) sur une base CE-CE, si cela est souhaité.

L'utilisation de la cryptographie sur une base PE-PE est laissée pour étude ultérieure.

13.2. Plan de contrôle (Control Plane)

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 garantir la sécurité, ni les connexions BGP ni les connexions LDP ne doivent être établies avec des pairs non fiables. L'option d'authentification MD5 de TCP/IP [TCP-MD5] doit être utilisée avec ces deux protocoles. Le protocole de routage au sein du réseau du SP doit également être sécurisé de manière similaire.

13.3. Sécurité des équipements P et PE (Security of P and PE Devices)

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

Les mesures habituelles doivent être prises pour garantir que le trafic IP provenant de l'Internet public ne puisse pas être utilisé pour modifier la configuration de ces équipements, ni pour lancer des attaques par déni de service (Denial of Service) contre eux.