Plus économiques que les réseaux privés sur ligne particulière, les réseaux privés virtuels (RPV) permettent d'ouvrir un véritable tunnel au sein des réseaux publics, qu'il s'agisse d'Internet ou du réseau téléphonique. Pour créer ce tunnel, il suffit d'encapsuler les paquets transmis dans les trames IP à l'aide de protocoles, dont PPTP (Point-to-Point Tunneling Protocol), L2TP (Layer 2 Tunneling Protocol), L2F (Layer 2 Forwarding) comptent parmi les plus courants. Ceux-ci étant relativement anciens, l'IETF (Internet Engineering Task Force) a été amené à concevoir de nouvelles normes pour élargir le champ d'adressage et sécuriser les échanges. Parmi les nouveaux protocoles dédiés aux RPV, IPSec se démarque par les gains substantiels qu'il apporte en termes d'authentification, d'intégrité et de confidentialité.

Depuis 1992, le groupe de travail IPSec de l'IETF planche sur ce protocole, avec l'objectif initial de sécuriser IPv4 (en attendant que IPv6 le soit). C'est à cette époque qu'ont commencé les premières soumissions de RFC (Request For Comment), qui ont donné lieu, sept ans plus tard, aux premières spécifications. Depuis, la nomenclature fournie par l'IETF a été progressivement appliquée par les constructeurs, avec toutefois des conformités parfois hasardeuses et des incompatibilités entre matériels.

D'un point de vue pratique, IPSec intervient au niveau de la couche 3 du modèle OSI (Open System Interconnection), avec le principe sous-jacent d'apporter une protection au niveau des paquets IP. Situé sur cette couche, il peut fonctionner selon deux modes de sécurisation : de bout en bout entre deux utilisateurs, ou de lien à lien sur des segments de réseau. Deux modes qui en font un protocole parfait pour la mise en place de RPV et, de manière générale, pour sécuriser tout accès distant. Il peut s'appliquer dans le cadre d'un mode de transport normal, auquel cas seule l'intégrité des données " utiles " du paquet IP sera assurée. Il peut aussi s'appliquer en mode tunnel et, dans ce cas, IPSec se chargera de la confidentialité de toutes les données. Pour ce faire, IPSec repose sur trois modules contenus dans la pile TCP/IP : IKE (Internet Key Exchange), AH (Authentification Header) et ESP (Encapsulation Security Payload).

Pour la mise en oeuvre d'IPSec, on établit en premier lieu deux liaisons logiques unidirectionnelles point à point entre les deux passerelles IPSec qui seront les extrémités du RPV. L'établissement de ces liaisons, baptisées Security Associations, donne lieu à des négociations de clés par le module IKE qui prend en charge la gestion de l'algorithme choisi par l'utilisateur. Les plus courants sont Blowfish, Triple DES (Data Encryption Standard) et RC5. Cependant, on assiste à l'arrivée des premiers routeurs mettant en oeuvre l'AES (Audio Engineering Society), un algorithme à courbes elliptiques. En effet, le chiffrement des données sera effectué selon les clés négociées lors de l'établissement du RPV. Il est possible de déterminer une durée de vie pour ces clés, de sorte que, en cours de connexion, un nouveau jeu de clés soit renégocié afin de modifier périodiquement l'algorithme de chiffrement.

Dans les cas où l'intégrité des données est la priorité, sans que la confidentialité du contenu et des correspondants ne soit primordiale, on ajoutera un en-tête AH aux trames IP. La partie AH du paquet représente une signature du contenu, chiffrée pour chaque paquet. Si, lors de la réception, cette signature ne correspond pas au contenu, le paquet doit être éliminé. À l'inverse, si la confidentialité des données prime sur celle des correspondants, les trames seront chiffrées selon le procédé ESP. Dans ce cas, l'en-tête IP contenant les adresses des correspondants est en " clair " , tandis que les données utiles du paquet (payload) sont chiffrées. En outre, des champs supplémentaires garantissent l'intégrité des paquets. Enfin, si l'on souhaite garantir la confidentialité des correspondants, il est nécessaire de mettre en place un mécanisme d'ESP en mode tunnel. Ce mode permet d'utiliser non plus l'en-tête IP du paquet d'origine, mais un en-tête contenant les adresses des passerelles en réseau, ce qui ne fournit aucune information sur les interlocuteurs.

Si, sur le papier, IPSec répond au cahier des charges des RPV, le déploiement de ceux-ci reste délicat à plus d'un titre. À commencer par la gestion des clés publiques et privées. Pour leur mise en oeuvre sur de grands réseaux de tunnels, on ne peut se contenter d'une gestion au cas par cas. Il est alors nécessaire de faire intervenir une infrastructure de gestion de clés (PKI). De même, dans le cadre d'échanges entre plusieurs sociétés (extranets en RPV), une politique de règles communes doit être définie avant l'installation des équipements, par exemple en caractérisant les certificats par des attributs propriétaires.

Enfin, l'administration d'IPSec reste encore à ce jour des plus délicates, à cause du manque patent d'outils qui lui sont nécessaires, et ce, même si IBM, Cisco et Bull travaillent activement au développement de consoles dédiées. Au demeurant, IPSec est aujourd'hui en passe de devenir le protocole le plus fédérateur en termes de sécurisation de réseau. La preuve en est que, sans même parler des grands équipementiers, Microsoft l'a installé dans Windows 2000 et que la plupart des Linux l'exploitent dans leurs piles TCP/IP. Notons que ce protocole sera mis en oeuvre en natif dans IPv6, le successeur très attendu d'IPv4, à l'horizon 2005.