Sorry, you need to enable JavaScript to visit this website.

Image CAPTCHA
Saisir les caractères affichés dans l'image.

GDOI: Le cryptage IPSEC any2any au sein d'un réseau privé

GDOI: Le cryptage IPSEC any2any au sein d'un réseau privé
2009-12-092013-02-11sécurité des réseauxfr
Le succès des offres de réseau étendu (WAN) basées sur des technologies comme MPLS ne sont plus à démontrer. 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...
Publié le 9 Décembre 2009 par Jean-François Audenard dans sécurité des réseaux


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 ? Le marché le dira. Néanmoins, il me semble diablement intéressant et prometteur.

3 Commentaires

  • 1 Août 2013
    2013-08-01
    par
    Steve Missoh
    Bonjour Jean-Francois
    je viens de lire votre article et visionner votre vidéo.
    Très bien fait et très instructif surtout que les docs en francais sur GETVPN sont très rares. J'ai cependant un cas d'utilisation urgent dont je voudrais discuter avec vous. Pourrais je avoir votre email afin de vous écrire ?
    merci d'avance
  • 28 Décembre 2009
    2013-08-01
    par
    Les termes ont effectivement leur importance. Je ferai en sorte de tourner 7 fois (au moins) mes doigts sur le clavier afin d'utiliser "chiffrement" en lieu et place de "cryptage".
    En vous souhaitant de bonnes fêtes de fin d'année.
    JF.
  • 24 Décembre 2009
    2013-08-01
    par
    Serge
    Bonjour,

    Même commentaire que pour votre post du 18/12

    Le terme « cryptage » est un anglicisme, tiré de l'anglais encryption. En français, on doit employer le mot chiffrement.

    Cela ne fait pas tout sérieux de retrouver ce type d'erreur en plus dans un blog sur la sécurité !!!

    Cordialement
    Serge

Ajouter un commentaire

comments

  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Tags HTML autorisés : <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd> <br>

Plain text

  • Aucune balise HTML autorisée.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.

Email HTML

  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
Image CAPTCHA
Saisir les caractères affichés dans l'image.
Changer d'affichage