<a href='/s/10p2kR1AJ' target='_self'>Retour à la page principale</a>
# VPN IPSec site à site - les protocoles
[TOC]
---
Aborder la thématique des réseaux privés virtuels (Virtual Private Networks ou VPNs) utilisant IPSec sans préciser les conditions dans lesquelles ces techniques sont utilisées est une gageure. Pire encore, justifier les choix effectués sur l'architecture réseau sans une présentation succincte du jeu de protocoles et d'algorithmes de cryptographie mis en œuvre rendrait la suite du document inexploitable. C'est la raison pour laquelle on présente ici un minimum d'éléments sur IPSec.
La raison d'être de cette section est de servir de référence sur les choix effectués par la suite. Lors des recherches en ligne sur IPSec, on trouve trop souvent des copies de fichiers de configuration peu ou pas commentés qui répondent à un contexte singulier. Ici, l'objectif est justifier les options retenues en fonction du contexte défini.
## Le retour de la triade CIA ... ou presque
Au niveau le plus général, en sécurité des systèmes d'information ([Information security](https://en.wikipedia.org/wiki/Information_security)), la lettre **C** correspond à *Confidentiality*, la lettre **I** correspond à *Integrity* et la lettre **A** correspond à *Availability*. Dans le contexte de ce document, seule l'interprétation de la lettre **A** diffère. Le terme *Availability* est remplacé par *Authentication*. La fameuse «triade CIA» est donc aussi un moyen mnémotechnique pertinent dans le contexte présent. Voir l'article [Concepts élémentaires en sécurité de l'information](https://inetdoc.net/articles/infosecconcepts/).
IPSec n'est pas un protocole unique mais un ensemble de protocoles définis par un organisme très connu : l'[IETF](https://www.ietf.org/) (Internet Engineering Task Force). Le but est de fournir un haut niveau de sécurité dans l'échange des paquets IP. On se situe donc au niveau de la couche réseau de la modélisation. Les services doivent utiliser la cryptographie et être interopérables. Les points clés sont :
* **Confidentialité** : l'émetteur chiffre les paquets avant de les transmettre sur l'Internet ou encore le réseau public.
* **Intégrité** : le récepteur vérifie que les paquets reçus n'ont pas été altérés lors de la transmission.
* **Authentification** : le récepteur vérifie l'identité de l'émetteur. Plusieurs méthodes d'authentification sont disponibles.
* **Clés partagées** ou *preshared keys*. La «clé secrète» est déposée à l'avance sur chaque extrémité. La même clé est utilisée durant les phases d'établissement des associations de sécurité.
* **Certificats numériques signés** ou *signed digital certificates*. Chaque extrémité détient un certificat propre contenant un couple clé privée/clé publique. Une extrémité utilise la clé privée pour signer les données à émettre tandis que l'autre extrémité utilise la clé publique pour vérifier les données reçues.
* **Authentification externe**. On fait appel à un service externe tel que Keberos ou Radius qui permet d'accéder aux différentes formes de couple nom d'utilisateur/mot de passe : *One Time Password* (OTP), token, biométrie, etc.
* **Anti rejeu** : le récepteur examine les paquets et rejette les paquets périmés (reçus en dehors de la fenêtre de temps prévue) et/ou répétés.
:::info
Dans le contexte de ce document, la méthode d'authentification utilise les clés partagées. Le trafic doit être sécurisé de façon permanente et continue entre deux sites «fixes».
:::
Les conditions d'utilisation des points ci-dessus sont négociées à l'aide du protocole IKE ([*Internet Key Exchange*](http://en.wikipedia.org/wiki/Internet_Key_Exchange)) et de la mise en place d'associations de sécurité SA ([*Security association*](http://en.wikipedia.org/wiki/Security_association)). Il est aussi possible de configurer manuellement les politiques de chiffrement et les algorithmes. Dans ce dernier cas, le protocole IKE est inutile.
## L'échange de clés Diffie-Hellman
Cette méthode est utilisée dans les échanges du protocole IKE pour générer un secret partagé entre les deux extrémités de façon sécurisée. Avec cette méthode, un «observateur» ayant capturé les échanges IKE ne peut pas remonter au secret partagé.
Le secret partagé est utilisé pour calculer une valeur qui sert ensuite aux calculs des clés utilisées dans les phases 1 et 2 du protocole IKE. Des groupes auxquels ont été associé une longueur de clé et une fonction de chiffrement doivent être choisis pour mettre en œuvre l'échange de clés. Plus la clé comprend un nombre de bits important, plus le secret est «solide». En contre partie, le temps de calcul est lui aussi plus important. Cette méthode est appelée à chaque établissement ou renouvellement d'association de sécurité.
Il faut ajouter à ce mécanisme d'échange de clés la technique appelée [*Perfect Forward Secrecy*](https://en.wikipedia.org/wiki/Forward_secrecy) (PFS). Avec cette technique, les calculs de clés sont plus sûrs dans la mesure où les nouveaux calculs de renouvellement de SA ne se font pas à partir des anciennes clés.
## Les deux protocoles de sécurisation IPSec : AH & ESP
En complément du protocole IKE qui établit un tunnel, IPSec s'appuie sur deux services qui peuvent être utilisés seuls ou associés.
Authentication Header, AH, protocole n°51
: Le protocole AH authentifie l'émetteur des données, contrôle l'intégrité du paquet IP (en-tête et charge utile) et assure le service anti rejeu. Il couvre donc les lettres **I** et **A** de la triade CIA.
Les traitements associés utilisent des algorithmes de «hachage» tels que [*Secure Hash Algorithm*](https://en.wikipedia.org/wiki/Secure_Hash_Algorithms) (SHA-1, SHA-256, etc.). Un algorithme de hachage est assocé à une clé issue de la méthode d'authentification choisie pour constituer un [*Hash-based Message Authentication Code*](https://en.wikipedia.org/wiki/HMAC) (HMAC).
L'en-tête AH est inséré à la suite de l'en-tête IP pour garantir l'intégrité et l'authenticité des données. On se protège ainsi contre toute altération du paquet lors de son transit.
Source : [Wikipedia](https://en.wikipedia.org/wiki/IPsec#/media/File:Ipsec-ah.svg)
Encapsulating Security Payload, ESP, protocole n°50
: Le protocole ESP se distingue du précédent par le chiffrement de la partie données avant encapsulation dans le paquet IP. On intègre ainsi la partie confidentialité aux fonctions de sécurisation. Ce protocole couvre donc les **trois lettres** de la triade CIA sur la partie charge utile du paquet.
Les traitements associés, en plus des algorithmes de hachage cités précédemment, font intervenir des algorithmes de chiffrement tels que [*Advanced Encryption Standard*](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) (AES).
Source : [wikipedia](https://en.wikipedia.org/wiki/IPsec#/media/File:Ipsec-esp-tunnel-and-transport.svg)
## Les deux modes de fonctionnement IPSec : Transport & Tunnel
*host-to-host transport mode*, mode transport
: Dans ce mode, les échanges de paquets IP sont sécurisés entre deux extrémités. Seule la charge utile ou *payload* est concernée par les traitements et l'en-tête du paquet IP est préservé pour permettre au routage de fonctionner de façon transparente.
network-to-network tunnel mode, mode tunnel
: Dans ce mode, les échanges de paquets IP sont sécurisés de réseau à réseau. La totalité du paquet IP (en-tête + charge utile) est encapsulée et un nouvel en-tête de paquet IP est créé.
Le choix entre ces deux modes de fonctionnement est un point essentiel dans la mise en œuvre d'un VPN IPSec. L'argumentation tourne souvent autour de l'inclusion ou non de l'en-tête de paquet IP dans les fonctions de sécurité de la triade CIA et du nombre de réseaux à faire transiter via le VPN site à site.
## L'établissement d'une association de sécurité : IKE & ISAKMP
L'objectif du mécanisme d'échange IKE, via le protocole ISAKMP, est de permettre à deux extrémités en communication d'établir une association de sécurité. Cette association demande au moins deux étapes.
IKE phase 1, ISAKMP-SA
: Durant cette première phase, il y a établissement d'une session sécurisée ISAKMP entre les deux extrémités que l'on appelle ISAKMP SA. C'est dans cette même phase que sont configurés les jeux de traitements utilisables (transform-set) : algorithmes de hachage, algorithmes de chiffrement et méthode d'authentification.
IKE phase 1.5
: Cette «phase intermédiaire» ne peut se dérouler que sous la protection du tunnel ISAKMP établi en phase 1. Elle est aussi appelée Extended Authentication (XAUTH). Ici, l'authentification utilisateur est étendue pour fournir des éléments de configuration supplémentaires à un client VPN : adresses IPv4 ou IPv6, masque réseau, serveur DNS, etc.
IKE phase 2, IPSec-SA
: Comme dans le cas précédent, cette phase ne peut se dérouler que sous la protection du tunnel ISAKMP établi en phase 1. À la différence de la phase 1, on ne parle plus d'une association de sécurité bidirectionnelle utilisant la même clé partagée entre les deux extrémités.
Ici, il faut établir deux associations unidirectionnelles entre les mêmes extrémités. Une fois que ces deux SA sont en place, le tunnel IPSec est actif. Les paramètres négociés sont quasiment les mêmes que lors de la phase 1 : algorithme de hachage, algorithme de chiffrement, groupe Diffie Hellman, informations anti rejeu, durée de vie de l'association de sécurité.
:::info
Dans le contexte de ce document, la phase 1.5 est sans objet dans la mesure où les deux extrémités du tunnel ISAKMP sont des routeurs dont les paramètres de configuration sont déjà connus.
:::
## La synthèse sur l'encapsulation
| Protocole | Transport | Tunnel |
| ------ | ----------------------------------------------------------------- | ------ |
| AH | IP <font color="red">AH</font> <font color="blue">data</font> | <font color="orange">IP</font> <font color="red">AH</font> IP <font color="blue">data</font> |
| ESP | IP <font color="green">ESP</font> <font color="blue">data</font> <font color="green">ESP-T</font> | <font color="orange">IP</font> <font color="green">ESP</font> IP <font color="blue">data</font> <font color="green">ESP-T</font> |
| AH+ESP | IP <font color="red">AH</font> <font color="green">ESP</font> <font color="blue">data</font> <font color="green">ESP-T</font> | <font color="orange">IP</font> <font color="red">AH</font> <font color="green">ESP</font> IP <font color="blue">data</font> <font color="green">ESP-T</font> |
## Le tunnel GRE ou comment acheminer le trafic multicast
Pour achever cette partie sur les principes du jeu de protocoles IPSec, il reste un dernier point très important à ajouter : ++IPSec seul ne peut véhiculer que le trafic unicast++. C'est un critère essentiel à prendre en compte lors du choix d'une solution d'encapsulation.
Dans le contexte de ce document, nous sommes apparemment face à un sérieux problème sachant que tous les échanges entre instances de protocoles de routage dynamique se font en multicast. Fort heureusement, il existe une solution : ++le tunnel GRE++.
À priori, les tunnels GRE ([*Generic Routing Encapsulation*](https://en.wikipedia.org/wiki/Generic_Routing_Encapsulation)) n'ont aucun rapport avec le jeu de protocoles IPSec. Ce protocole, initialement développé par Cisco™, a été conçu pour encapsuler n'importe quel protocole dans un tunel IP. Il a ensuite été étendu à l'encapsulation IP dans IP. Associé à IPSec, il permet de dépasser la limitation de ce dernier au trafic unicast.
Le couple GRE + IPSec peut être assimilé à un mode tunnel sans restriction sur la nature du trafic véhiculé.
Dans la représentation ci-dessus, le champ **IP GRE Header** correspond à l'en-tête IP introduit par l'utilisation du tunnel GRE.
Cette représentation graphique montre que l'utilisation du mode transport avec le protocole ESP offre généralement un niveau de sécurité suffisant sachant que seul l'en-tête IP lié à l'utilisation du tunnel GRE est exposé. L'utilisation du mode tunnel implique l'encapsulation d'un en-tête IP supplémentaire qui pénalise l'espace réservé à la charge utile.
<a href='/s/10p2kR1AJ' target='_self'>Retour à la page principale</a>