Le cryptage ipsec au sein d'un réseau privé

Le succès des offres de réseau étendu (WAN) basées sur des technologies comme MPLS ne sont plus à démontrer : Ce type de service réseau permet d'interconnecter entre-eux tous les sites d'une entreprise qu'ils soient en France ou à l'international. Au sein de ce type de réseau, les flux internes d'une entreprise sont isolés de ceux des autres entreprises.

Les entreprises utilisant ce type de service réseau sont de tailles et de natures très variables : Grandes institutions, organismes bancaires, assurances, industries et PME en sont friandes. La raison de cet attrait vient du fait que les engagements de qualité de service
et de sécurité fournis dans le cadre de leur contrat de service sont clairement plus forts que dans un contexte Internet.

Mais pour certaines activités, cela n'est tout de même pas suffisant. En effet, pour certains secteurs d'activités comme la banque, les assurances, les industries sensibles ou encore la défense et le secteur gouvernemental, l'isolation des flux vis-à-vis des tiers ne réponds pas
pleinement aux besoins : Les flux doivent être cryptés.
Le cryptage des flux en interne d'un réseau privé MPLS permet en effet de s'assurer de la confidentialité des communications dans l'éventualité d'une écoute à des fins d'intelligence économique ou d'espionnage industriel. Mais le besoin le plus fréquent est de répondre
à la réglementation en vigueur de certains secteurs d'activités comme la banque.

Historiquement, les communications au sein d'un réseau privé étaient basées sur le modèle client-serveur : D'un coté les utilisateurs ou "consommateurs" d'informations et de l'autre les founrisseurs de services et de contenus. Dans un tel modèle, les flux se concentrent vers les sites hébergeant les données ou serveurs : C'est le mode dit en "étoile", "client-serveur" ou encore "hub&spoke" dans la terminologie des personnes réseaux.

Dans un tel contexte, la solution "standard" est de mettre en place des tunnels IPSEC entre chacun des sites (les "spoke" ou "client") et chacun des datacenters (les "bug" ou "serveur"). Il y a autant de tunnels IPSEC à configurer qu'il y a de "relations" à mettre en place : Si les
applications sont réparties sur 2 datacenters avors chaque site aura un tunnel IPSEC distinct avec chacun d'entre-eux.
Déjà, on peut pressentir la complexité d'un tel système quand le nombre de sites approche la centaine. Mais ceci dit, cela reste gérable et reste bien réel.

Mais, les usages évoluant, la donne change et plutôt radicalement : La convergence vers le "tout IP" fait que le réseau IP privé d'une entreprise est de plus en plus utilisé pour assurer le transport d'applications brisant le sacro-saint modèle "client-serveur".
La VoIP en est un exemple criant. D'un coté, les flux de signalisation (pour trouver l'adresse IP de son correspondant et établir la connexion) restent en mode "client-serveur" mais les flux de données (cad la voix numérisée) sont prévus pour passer en direct d'un téléphone IP à un autre téléphone IP.
Faire passer obligatoirement ces flux via le site central est peu acceptable, et ce pour plusieurs raisons :
- Consommation excessive (et inutile) de la bande passante au niveau du site central.
- Doublement des temps de transit : Les flux vont et viennent via un tiers alors qu'ils pourraient s'échanger en direct
- Augmentation des temps de latence (on crypte/décrypte une fois de trop)
- Surcharge au niveau des boitiers de cryptage (Principalement sur le site central).

En outre, les sociétés demandent à ce que leur réseau s'adapte à leurs usages : Un site qui était "client" peut devenir "serveur" ou un nouveau site "serveur" peut être mis en place.
Dans un contexte tunnel IPSEC en "point à point", on devra attendre plusieurs jours (voir pire) pour que les tunnels correspondants soient mis en place... Est-ce souple ou "agile" ? clairement non.... réseau devient un frein, un limiteur au business alors qu'il est là justement pour l'inverse !

Certains pourraient se dire "dans ce cas, il ne reste qu'a mettre en place des tunnels IPSEC directement entre chacun des sites".
Oui, cela fonctionnera tout à fait. Le problème c'est que le nombre de tunnels va exploser et être ingérable dès que le nombre de sites dépasse une dizaine : 10 = 100 tunnels. En fait la
formule est assez simple : pour un réseau dit "complètement maillé" (ou "fully-meshed") en tunnels IPSEC, pour n sites vous devez mettre en place n x n tunnels....et bien sur il faut gérer et superviser ces tunnels : clairement peu "scalable" pour rester dans les anglicismes.

Pour répondre a ce besoin de crypter les communications tout en conservant toute la souplesse d'un réseau privé IP basé sur MPLS, la technologie GDOI est une solution pleine de promesses.

Sans rentrer dans les détails, GDOI (Group Domain Of Interpretation) permet de définir des domaines de cryptage entre plusieurs éléments du réseau : En lieu et place de configurer
un tunnel IPSEC entre deux routeurs précis, il est possible grâce à GDOI de définir "un groupe de routeurs se faisant mutuellement confiance et capables d'échanger entre-eux des données de façon cryptée et efficace". Le tout étant piloté ou organisé par un clef d'orchestre en central.
L'une des premières implémentations de ce protocole standardisé par l'IETF (RFC 3547) est celle de CISCO : GetVPN (Group Encrypted Transport VPN).

Dans le contexte GetVPN, les routeurs de site sont des Group Members (GM) : ils sont gérés de façon centralisée par le Key Server (KS). Une fois l'authentification des GM effectuée
par le KS, ce dernier distribue les clefs de chiffrement aux membres du groupe qui vont ainsi pouvoir crypter les communications.

Une autre caractéristique très intéressante de cette technologie réside aussi le fait qu'elle s'insère de façon astucieuse dans les couches IP : Les entêtes IP sont protégées mais restent utilisées pour le routage des paquets au sein du réseau : On évite ainsi d'avoir à gérer un réseau dit "overlay" (sur-couche) et on conserve aussi les paramètres de qualité de service.

On obtient le meilleur de deux mondes en même temps : Le fonctionnement du réseau IP reste le même et les communications sont chiffrées.

GDOI servira-t-il de déclencheur pour la généralisation du cryptage au sein des réseaux privés ?

Source : http://blogs.orange-business.com/securite/2009/12/gdoi-le-cryptage-ipsec-any2any-au-sein-dun-reseau-prive.html