L’un des changements majeurs du domaine des Technologies WANs est l’apparition de la solution SD-WAN et son influence sur la gestion du trafic de l’entreprise, ce trafic qui migre progressivement vers le Cloud et qui force l’entreprise à s’appuyer sur des transports (MPLS, INTERNET etc..) communément appelé couche Underlay afin d’offir une meilleure rentabilité pour leurs employés et leurs partenaires. L’impact de la solution SD-WAN sur le Business, nous a ramené a se poser la question suivante: Techniquement quelle est cette valeur ajoutée par SD-WAN? pour répondre à cette question, il y’a pas mieux que de faire un pas en arrière dans le passé et analyser ce que nous utilisions comme technologie WAN, la plus répandue DMVPN, quelles sont les problématiques et les limites de ses technologies traditionnelles, et comment le SD-WAN comme remède palliatif est venu remédier à ses limites. A travers cet article on verra ce face à face DMVPN vs SD-WAN.
Avec Cisco SD-WAN, vous pouvez implémenter n’importe quelle topologie. Dans Cisco SD-WAN, on peut avoir une combinaison de topologie Hub-and-Spoke et Spoke-to-Spoke, ceci est possible grace au concept de VPN (VRF), avec SD-WAN, on peut avoir une VRF en Hub-and-Spoke et une autre VRF en Spoke-to-Spoke. Mettre en place ces topologies disparates avec le traditionnel DMVPN n’est pas aisé.
Le Hub joue un rôle central dans le Control Plane et le Data Plane. C’est pour cette raison qu’il est recommandé de déployer au moins deux Hubs. Maintenant le Hub comme point central pose-t-il vraiment un problème potentiel?, si le Hub est hors service, les tunnels seront down, et les spokes n’peuvent plus solliciter le NHS (Hub), ainsi en perdant la connectivité du Hub, le trafic entre les Spokes s’en trouve impacté aussi.
Dans Cisco SD-WAN, le Hub n’a pas de rôle spécial. En fait en séparant le Control Plane et le Data Plane et en délocalisant le Control Plane à un controleur appelé vSmart, le Hub vEdge dans le SD-WAN aura le meme role que les autre Spokes vEdge, c’est à dire s’occuper juste du Data Plane.
La perte de connectivité du Hub n’affectera nullement la connectivité entre Spokes. Ce qui permet d’implémenter un design résilient.
Dans un réseau DMVPN combiné avec IPsec, l’administrateur doit mettre en place l’authentication des Routeurs participants dans le DMVPN, elle peut se faire soit avec PSK (Pre-shared Key) ou bien des certificats (Rappelez vous de la commande « auth » dans la policy isakamp ainsi que la command « crypto isakmp key address »).
la méthode d’authentification la plus utilisée est le PSK, car elle est simple a configurer, c’est juste un mot de passe secret entre les deux routeurs VPN mais ce n’est pas la plus sécurisé. Souvent dans une architecture avec une plusieurs Spokes, le meme PSK (le meme mot de passe) est utilisé dans tous les routeurs, pire encore, la clé n’est jamais modifiée.
La méthode la plus sécurisée est d’utiliser les certificats au détriment du Pre-Shared Key. Ce qui implique que l’entreprise doit posséder sa propre infrastructure PKI. Cette méthode est plus sécurisée certes mais elle pose une complexité dans la mise en oeuvre de cette PKI et la gestion des certificats, comment les distribuer à tous les routeurs?
L’IPsec aussi est composée de deux associations de sécurité SAs, appelées Phase 1 (Isakmp) et Phase 2 (IPsec). Le rôle de la Phase 1 est proteger la négociation de la phase 2, tandis que la phase 2 a comme rôle la protection des données.
Mais qu’est ce qui est négocié dans la Phase 2, c’est tout simplement le protocole ESP (ou éventuellement AH), c’est à dire l’algorithme de cryptage des données et l’algorithme d’intégrité.
En vérité tous routeurs participants dans le DMVPN en Spoke-to-Spoke doivent negocier deux tunnels:
Tunnel ISAKMP (Phase 1), par exemple 3DES, PSK et sha.
Tunnel IPsec (Phase 2), par exemple AES, HMAC-SHA.
Pour chaque tunnel, des négociations de paramètres des deux phases, generer la clé de cryptage pour chaque tunnel, vérifier l’identité (PSK ou par certificat) de chaque spoke. Sur un ensemble d’un design complexe, les ressources des routeurs s’en trouveront impactés. Et la gestion de toutes ses implémentations devient complexe.
Avec Cisco SD-WAN, tous les routeurs vEdges sont déja authentifiés pour joindre le Overlay du SD-WAN. Pratiquement parlant, lors du déploiement initial, pour que les routeurs Edges puissent joindre le Overlay et s’enregistrent dans vManage, il faut qu’ils s’authentifient avec des certificats avec le vBond (l’Orchestrateur), le vSmart (le Contrôleur) et vManage (la console de management). Le vSmart le controleur possede une WhiteList contenant les numéros de séries de ses vEdges (les Hubs et les Spokes). Par conséquent tout routeur vEdge souhaitant joindre le Overlay, il doit présenter un certificat valide et un numéro de série présent dans la WhiteList.
Si l’équipement est volé pour une raison ou une autre, il suffit juste d’invalider le certificat ou tout simplement le supprimer de la WhiteList. C’est plus sécurisé que le PSK dans le DMVPN Traditionnel et une gestion simplifié des certificats.
Le deuxième point important est que les routeurs vEdges (Data Plane) une fois authentifiés, établiront automatiquement des tunnels DTLS avec le vSmart le controleur.
A partir de la, dans Cisco SD-WAN, nous avons des routeurs dont l’identité est verifiée et des tunnels DTLS établis avec le vSmart.
Afin d’optimiser les négociations IPsec, la phase 1 qu’on connait traditionnellement et qu’on a décrit auparavant d’une maniere succinte n’a pas lieu d’être entre les routeurs Edges pour generer les clés de cryptage (ses clés qui seront utilisées dans la phase 2 pour protéger les données). Mais plutôt entre les routeurs Edges et le controleur vSmart. Et plus judicieusement, les routeurs Edges et vSmart vont utiliser les tunnels DTLS déja en place pour négocier les clés de cryptage. SD-WAN n’a plus besoin de la fameuse Phase 1 ISAKMP. Ses clés seront negociées à travers les tunnels DTLS à l’aide du protocol OMP.
Qu’en est-il du routage?, les protocoles les plus utilisés dans DMVPN sont EIGRP et BGP basé sur les destinations, les deux ont fait leur preuves mais plus aujourd’hui ou le besoin en terme de routage application sensible à la latence, le jitter et le packet loss est devenu vital, comme s’assurer que notre visioconference passe par un chemin dont la latence, le jitter et le packet loss sont assez acceptable pour une réunion virtuelle agréable? les protocoles IGP traditionnels n’ont pas cette intelligence. En d’autre termes un protocole IGP comme OSPF choisi toujours le meilleur chemin en se basant sur la bande passance, imaginons deux chemins A (Lien 1G) et B (Lien 10G) pour une destination 10.1.1.0/24. Il est clair pour OSPF le chemin B est meilleur. Et si le chemin B présente un pourcentage de packet loss supérieur à 1% et un jitter dépassant 30 ms. Ca sera dramatique pour notre visioconference.
Ajoutons à cela le control des mises à jour de routage, avec les protocoles IGP traditionnels, les route-map, les prefix-list et les access-list ont fait aussi leur preuve mais dans un réseau complexe avec énormément de routeurs, la gestion de la configuration devient fastidieuse car tout simplement ce n’est pas centralisé. Chaque routeur est responsable de son propre Control Plane.
Avec Cisco SD-WAN, l’introduction du routage par application appelé Application Aware Routing ou tout bonnement AAR permet justement à travers des policies qui ressemblent à des route map, de router le trafic voip par exemple ou les applications critiques si le lien présente des valeurs acceptable de la latence, le jitter et le packet loss. Si un dépassement d’un seuil prédéfini est détecté, l’application est rerouté via un autre chemin. Pour le filtrage du Controle Plane ou les policies, y’a plus de soucis à se faire, c’est implementé dans vManage, envoyé et appliqué dans vSmart, les mises à jour de routage (OMP) sont toujours envoyés par les routeurs vEdges (les spokes) au vSmart, on n’a plus besoin de policy de controle plane et filtrage de mise à jour dans les spokes, c’est le vSmart qui hérite ses policies du vManage et qui les applique dans l’overlay entre les spokes. Gérer et Contrôler les mises à jour de routage dans un point central vSmart est moins pénible.
Nicolas
avril 27, 2021Merci pour cette belle comparaison.