Vous êtes sur la page 1sur 70

PROTOCOLE IP SEC

• 1. Problématique
• 2. Protection du trafic par Ipsec
• 3. Politique de sécurité : associations de sécurité
3.1 Contenu
3.2 Choix
3.3 Bases de données SPD et SAD
3.4 Traitement des paquets sortants
3.5 Traitement des paquets entrants

4. En-tête d’authentification AH
4.1 Modes de protection
4.2 Contenu
4.3 Calcul de l’authentificateur
• 5. En-tête ESP
• 5.1 Modes
• 5.2 Contenu
• 5.3 Construction
• 5.4 Extraction

• 6. IPsec appliqué au protocole IPv6


• 7. Gestion des associations de sécurité
• 8. Distributions des clés publiques

9. Incompatibilité entre IPsec et la traduction


d’adresses
9.1 Problèmes de compatibilité
9.2 Solutions préconisées
10. Autres problèmes liés à l’utilisation d’Ipsec

11. Évolutions d'Ipsec

12. Alternatives à Ipsec

13. Conclusion
INTRODUCTION

Pour faciliter les communications inter‐ et intra-entreprises, et ainsi pour
 

améliorer leurs relations commerciales et leur productivité, de


nombreuses entreprises se connectent à l'Internet, voire se tournent vers
des sociétés spécialisées (fournisseurs d'accès Internet, opérateurs...)
pour souscrire un service de VPN (Virtual Private Network). Ces réseaux
privés virtuels consistent à interconnecter les réseaux d’une ou plusieurs
entreprises au travers d'une infrastructure de réseau public, en
garantissant, dans la plupart des cas, une certaine qualité de service.
• Dès qu'une entreprise effectue des échanges au travers d'un réseau
public, sans verser dans la paranoïa, il est important de rester très
prudent. En effet, rien ne prouve que ces échanges ne feront pas l'objet
d'écoutes lors de leur transfert et qu'ainsi leur teneur ne sera pas révélée
à un tiers. C'est l'une des multiples formes que peut prendre l'espionnage
industriel. De plus, rien n’assure non plus que le trafic reçu provienne bien
du terminal déclaré et qu'il n'est pas issu d'un terminal malveillant ayant
usurpé l'identité d'un terminal légitime.
• Pour répondre à cette problématique, la solution la plus naturelle et la
plus répandue consiste à utiliser le protocole IPsec (IP security), la version
sécurisée d'IP. Ce protocole proposé par l'Internet Engineering Task Force
(IETF) permet en effet d'authentifier l’origine de paquets IP et de garantir
leur confidentialité et leur intégrité. Du fait que la très grande majorité
des réseaux d'entreprise repose sur le protocole IP, IPsec apparaît comme
la solution la plus naturelle.
• IPsec est d'ailleurs proposé dans quasiment toutes les offres
commerciales de VPN pour assurer la protection des échanges IP, et ce
quel que soit le type de réseau de transport exploité dans l'interconnexion
(MPLS, IP...).
• Cet article décrit le protocole IPsec, en particulier les deux protocoles AH
(Authentication Header) et ESP (Encapsulating Security Payload), ainsi que
les différents modes d'utilisation. Les problèmes de compatibilité d’IPsec
avec les mécanismes de base comme la traduction d’adresses et la
fragmentation sont exposés, ainsi que les solutions de sécurité
alternatives de type SSL et SHTTP à.
• 1. Problématique
 
• Le trafic IP en transit peut être la cible d’attaques malveillantes. Parmi ces
attaques, on peut citer classiquement :
• l’écoute (IP sniffing). Une personne malveillante se place à un endroit du
réseau et « écoute » le trafic échangé. Pour réaliser cette attaque, il faut
parvenir à introduire sur un réseau un analyseur de protocoles, ce qui
permettra d’espionner les communications et de récupérer des
informations confidentielles en transit comme des mots de passe ;
• l’usurpation d’identité (IP spoofing). Une personne contacte un
équipement en se faisant passer pour quelqu’un d’autre. L’équipement
contacté croit être en communication avec la personne dont l’identité est
usurpée et communique alors des informations pouvant être
confidentielles. Cela consiste généralement à remplacer l’adresse IP d’une
station par l’adresse IP d’un terminal légitime.
• Afin de se prémunir contre ce type d’attaque, différents mécanismes
classiquement utilisés en sécurité existent. Les deux premiers sont relatifs
à l’attaque.
Figure 1 - Chiffrement/déchiffrement de paquets IP
• Le chiffrement permet à l’émetteur de se prémunir contre les écoutes en ne
rendant ses données compréhensibles que par les équipements du réseau
autorisés. Il fait appel à deux équipements de sécurité, l’un se chargeant de
chiffrer les données émises et l’autre de les déchiffrer à la réception. Dans le
cas typique où deux réseaux privés sont interconnectés par l’Internet, comme
l’illustre la figure 1, les équipements placés à l’entrée des sites sont appelés des
passerelles de sécurité. La passerelle de sécurité du site émetteur (A) chiffre
les données M émises par un terminal de A. Les données chiffrées obtenues,
notées #&@ sur la figure 1, n’ont de signification que pour la passerelle de
sécurité du site récepteur (B). À la réception des données chiffrées, la
passerelle de B les déchiffre, obtient les données originales M et les transmet
au terminal destinataire de son site. Le chiffrement utilise des outils
cryptographiques, c’est-à-dire généralement des algorithmes de chiffrement
qui sont publiquement connus. La confidentialité des données émises est
obtenue en faisant dépendre le résultat du chiffrement de l’algorithme utilisé,
mais surtout des informations secrètes qui doivent être connues uniquement
des équipements de sécurité réalisant le chiffrement/déchiffrement. Ces
informations secrètes sont appelées clés de chiffrement et sont notées KAB sur
la figure 1 car elles sont connues des passerelles de A et B.
• L’authentificateur est ajouté aux données émises M par la passerelle de
sécurité du site émetteur A dans le cas de l’interconnexion de deux
réseaux privés distants (figure 2). Cet authentificateur garantit à la
passerelle du site B que les données reçues proviennent bien de
l’équipement attendu. Il permet ainsi de se prémunir contre les
usurpations d’identité. Il a également pour rôle en général de garantir
l’intégrité des données, c’est-à-dire d’offrir la garantie que les données
reçues n’ont subi aucune modification lors de leur transfert sur le réseau.
Figure 2 - L’authentificateur est introduit par la passerelle de
sécurité du site A émetteur et extrait/vérifié par l’équipement
du site B récepteur
•  

• Contre les attaques portant sur le trafic IP, la solution décrite consiste à
modifier le protocole IP pour réaliser le chiffrement des paquets IP et y
introduire un authentificateur. La version protégée du protocole IP est
appelée IPsec et fait appel aux protocoles AH (Authentication Header) et
ESP (Encapsulating Security Payload). Ces deux protocoles tels que proposés
par l'IETF dans les RFC 2402  et 2406  sont décrits aux paragraphes 4 et 5. Ils
reposent sur la définition d'une politique de sécurité liée aux besoins de
sécurité du réseau et présentée au paragraphe 3. Les autres paragraphes se
focalisent sur les points précis suivants : les problèmes de compatibilité
entre IPsec et les mécanismes de traduction d’adresses, de fragmentation,
et du DHCP (Dynamic Host Configuration Protocol), les particularités d'IPsec
appliquées à un environnement IPv6, les solutions adoptées par l’IETF pour
gérer la sécurité dans les réseaux IP et les solutions alternatives à IPsec 
 
• 2. Protection du trafic par IPsec
 
• Afin de se prémunir contre les écoutes et les usurpations d’identité, le
groupe ipsec de l’IETF a modifié le protocole IPv4 pour permettre de :
• chiffrer les paquets IP (leur contenu seul ou le paquet entier) ;
• introduire un authentificateur permettant d’authentifier l’équipement
émetteur et de contrôler l’intégrité de tout ou partie du paquet IP.
• Ainsi, deux nouveaux protocoles IPv4 dédiés à la sécurité ont été définis
et consistent en deux nouveaux en-têtes (qui sont encore appelés
extensions pour la nouvelle génération IPv6 du proto- cole IP) :
• l’en-tête d’authentification (Authentication Header : AH) contient entre
autres un authentificateur. Il permet donc de vérifier l’identité de
l’équipement de sécurité émetteur et de contrôler l’intégrité des données.
Il permet optionnellement de détecter si les données reçues n’ont pas été
précédemment reçues (ceci pour éviter qu’une personne malveillante
ayant réussi à capturer un paquet légitime sur le réseau ne puisse rejouer
un paquet vers le même destinataire) ;
• l’en-tête ESP (Encapsulating Security Payload) permet de transporter un
paquet IP tout ou en partie chiffré, ainsi qu’un authentificateur offrant la
même gamme de services que l’en-tête d’authentification.
• Ces en-têtes permettent tous deux d’authentifier l’équipement de
sécurité émetteur. En fait, suivant l’en-tête choisi, l’authentificateur ne
protège pas les mêmes champs. Cela s’avère particulièrement utile selon
le mode de protection utilisé (voir ci-après) ou si une traduction d’adresse
est réalisée.
• Comme le précise le RFC 2401 , la protection des paquets IP peut être
réalisée de deux manières :
• de bout en bout. Seuls les terminaux mettent en place le protocole IPsec.
La communication est protégée entre les terminaux qui ont la charge de
construire et d’analyser les en-têtes de sécurité IPsec. Par rapport aux
schémas des figures 1 et 2, les logiciels réalisant la protection des paquets
IP dans les passerelles de sécurité sont en fait déportés dans les terminaux
source et destinataire des sites A et B ;
• sur des segments de réseau. Un ou plusieurs équipements intermédiaires
du réseau (couramment appelés passerelles de sécurité) sont impliqués
dans la protection des communications. La communication peut être
protégée entre un terminal et une passerelle ou bien entre deux
passerelles (comme le schématisent les figures 1 et 2). Notons que la
fonction de passerelle peut être intégrée dans un routeur sous forme
logicielle ou se présenter sous la forme d’un équipement physique à part.
Ce dernier est alors appelé chiffreur IP s’il ne rend que le service de
confidentialité des données.
• Selon le type de protection sélectionné, deux modes de protection
utilisant ces en-têtes sont disponibles :
• le mode transport assure uniquement la protection de certains champs
du paquet IP. Dans l’exemple de la figure 3, où seul le chiffrement des
données est requis, seul le contenu du paquet original est chiffré par le
logiciel IPsec du terminal émetteur a. Le mode transport n’est utilisable
que dans le cas d’une protection de bout en bout entre terminaux ;
• le mode tunnel s’applique à un tunnel IP. L’équipement tunnelier
réalisant le tunnel IP a pour fonction d’encapsuler le paquet IP lui arrivant
dans un nouveau paquet IP (figure 4). La protection qu’il met en place doit
porter sur tout le paquet IP entrant, ainsi que sur certains champs du
nouveau paquet IP construit. Ce mode peut être indifféremment utilisé
pour une protection de bout en bout ou une protection sur des segments
de réseau. La figure 5 montre un exemple faisant intervenir des
équipements tunneliers A et B des sites correspondants qui se chargent
de chiffrer les paquets IP entiers (contenant les adresses a et b des
terminaux source et destinataire) et de les encapsuler dans de nouveaux
paquets IP portant les adresses A et B des tunneliers.
Figure 3 - Exemple du chiffrement de paquets IP dans le cas du
mode transport
Figure 4 - Protection des paquets IP au niveau des tunneliers
Figure 5 - Exemple du chiffrement de paquets IP dans le cas
d’un tunnel IP
• 3. Politique de sécurité : associations de
sécurité

• 3.1 Contenu

3.2 Choix

3.3 Bases de données SPD et SAD

3.4 Traitement des paquets sortants

3.5 Traitement des paquets entrants


• Politique de sécurité
• La politique de sécurité appliquée sur un site est l’ensemble des
paramètres de sécurité nécessaires à la protection du site. Cela regroupe
les mécanismes de sécurité pour protéger les connexions, ces derniers
nécessitant généralement des précisions supplémentaires comme le type
d’algorithme de chiffrement et les clés de chiffrement à utiliser.
• La politique de sécurité pour l’IPsec se décline sous forme d’associations
de sécurité. Initialement, les deux équipements de sécurité (terminaux,
passerelles de sécurité) qui veulent protéger leurs échanges disposent
chacun de leur propre politique de sécurité dictée par leur officier de
sécurité. Lorsqu’ils souhaitent entrer en communication, ils doivent, en
fonction de leur politique de sécurité, se mettre d’accord sur le type d’en-
tête de sécurité à introduire/extraire dans les paquets IP, ainsi que les
services et les paramètres de sécurité (algorithmes et clés de chiffrement,
etc.) à utiliser en vue de protéger les échanges de paquets IP. C’est le
résultat de cette négociation qui est appelé association de sécurité.
• Une association de sécurité est identifiée par le triplet : indice de
paramètre de sécurité ou SPI (Security Parameters Index), adresse de
l'équipement de sécurité homologue et protocole de sécurité AH ou ESP.
Cela permet à un équipement de sécurité de participer à plusieurs
associations de sécurité et de protéger une communication avec une ou
plusieurs associations de sécurité.
• Exemple :
• il est possible que deux équipements de sécurité protègent une
communication en utilisant les deux en-têtes AH et ESP, auquel cas les
équipements doivent gérer deux associations de sécurité.
• Une association de sécurité est unidirectionnelle. Une communication
bidirectionnelle passée entre deux terminaux A et B nécessite donc
l’intervention de deux associations de sécurité, celle utilisée par A pour
protéger les datagrammes de A vers B et celle utilisée par B pour la
protection des datagrammes de B vers A.

• 3.1 Contenu
• Une association de sécurité contient entre autres :
• l'algorithme de chiffrement, les clés de chiffrement, etc., utilisés pour
générer l’en-tête ESP si le service de confidentialité est sélectionné ;
• l'algorithme d'authentification, les clés de chiffrement, etc., utilisés pour
générer l'en-tête ESP si le service d'authentification est sélectionné ;
• l'algorithme d'authentification, les clés de chiffrement, etc., utilisés pour
générer l’en-tête d'authentification ;
• la durée de vie de l’association. La sécurité est fondée sur le principe
suivant : plus une clé de chiffrement est utilisée, plus il est facile pour une
personne malveillante de deviner la valeur de cette clé.
• Ainsi, il est nécessaire de convenir périodiquement d’une nouvelle clé de
chiffrement. Une association de sécurité doit donc être régulièrement
renouvelée ;
• le mode du protocole IPsec : tunnel ou transport.

• 3.2 Choix
• Un terminal ou une passerelle de sécurité désirant construire un en-tête de
sécurité peut choisir l’association de sécurité à appliquer en fonction des
paramètres suivants (appelés encore selector dans le RFC 2401 ) :
• l’adresse IP source ;
• l’identité de l’utilisateur ;
• l’identité de l’équipement utilisé ;
• l’adresse IP de destination ;
• le niveau de sensibilité des données ;
• le protocole de niveau transport obtenu dans le champ en-tête suivant du
paquet IP ;
• les ports source et destination (comme les ports TCP ou UDP).
• Il faut noter que la plupart des implémentations et des produits mettant
en œuvre IPsec se limitent à l'adresse IP de l'équipement de sécurité
distant.
• Selector : un ensemble de champs de paquets IP exploités par un
équipement IPsec pour déterminer l'action à entreprendre sur les paquets
IP, voire l’association de sécurité à appliquer.

• 3.3 Bases de données SPD et SAD


• Afin de rendre les implémentations IPsec homogènes d'un constructeur à
l'autre, l'IETF encourage vivement les constructeurs à distinguer deux
bases de données.
• SPD (Security Policy Database) indique grossièrement la politique de
sécurité à mettre en œuvre sur chaque paquet IP. En fonction des valeurs
des champs inclus dans les paquets (cf. liste donnée au paragraphe 3.2), la
base SPD précise le traitement à opérer sur le paquet. Trois actions sont
possibles ; l'action Discard conduit à la destruction du paquet, ce type de
paquet étant interdit ; l'action Bypass IPsec indique que le paquet est
autorisé et qu'il sera émis tel quel sur le réseau ; enfin l'action Apply IPsec
oblige à protéger le ou les paquets avant toute émission, et ce avec une
association de sécurité particulière dont le détail est fourni dans la base
SAD.
• SAD (Security Association Database) précise tous les paramètres définis
pour les associations de sécurité. Les associations de sécurité sont toutes
identifiées par le triplet : SPI, protocole AH ou ESP et adresse de
l'équipement IPsec distant. Les paramètres des associations sont ceux
listés au paragraphe 3.1.
• Les paragraphes 3.4 et 3.5 décrivent de façon plus détaillée les traitements
effectués par les équipements de sécurité suivant qu'ils émettent des
paquets IP sur le réseau non sûr ou qu'ils reçoivent des paquets.

• 3.4 Traitement des paquets sortants


• Sont décrits ici les traitements mis en jeu au niveau d'une passerelle IPsec
lorsqu'elle reçoit un paquet émis par une machine interne et à émettre sur
le réseau public (figure 6). Ils font intervenir les deux bases de données
SPD et SAD.
• Comme indiqué sur la figure 6, en cas de réception d'un paquet IP émis par
une machine interne, la passerelle IPsec analyse les champs inclus dans le
paquet et, en fonction des « selector » définis, elle identifie dans la base
SPD le traitement à réaliser sur le paquet (étape 1).
• Trois traitements sont possibles (étape 2) :
• si le paquet est interdit, il est rejeté (action Discard ) ;
• si le paquet est autorisé et ne requiert aucune protection, il est transféré
sur le réseau public tel quel (action Bypass IPsec ) ;
• si le paquet est autorisé mais qu'il nécessite une protection (action Apply
SA ), la base SPD indique de quelle association de sécurité il s'agit. Il reste
donc à la passerelle IPsec à consulter la base SAD et à construire les en-
têtes IPsec conformément à l’association de sécurité. Le paquet protégé
sera ensuite émis sur le réseau public.
• Il faut noter que la figure 6 présente le cas d'un tunnel IPsec établi entre
deux équipements dont une passerelle IPsec, mais les traitements
seraient identiques depuis un terminal IPsec avec la possibilité d'utiliser le
mode tunnel ou transport.
• Il faut aussi remarquer que la grande majorité des passerelles IPsec se
limite à analyser l'adresse de destination des paquets IP sortants. Ainsi,
dans la base SPD, c'est uniquement l'adresse de destination qui détermine
l’association de sécurité à mettre en place.

• 3.5 Traitement des paquets entrants
• Supposons maintenant que la passerelle IPsec reçoive des paquets
protégés depuis le réseau public (figure 7). Elle doit tout d'abord extraire
les champs (SPI, protocole AH ou ESP, adresse source) lui permettant
d'identifier l’association de sécurité utilisée par la passerelle IPsec
émettrice (étape 1). La passerelle consulte la base SAD et récupère les
paramètres de sécurité correspondants (étape 2). Grâce à ces paramètres,
elle est à même de mettre en œuvre un sous-ensemble des fonctions
IPsec : déchiffrement, vérification de l’authentificateur, etc. (étape 3).
Figure 6 - Traitement de paquets IP par la passerelle IPsec
dans le sens sortant
Figure 7 - Traitement de paquets IP par la passerelle IPsec dans
le sens entrant
• La plupart des implémentations d'IPsec s'arrêtent à ce stade, ce qui
amoindrit leur niveau de sécurité. En effet, il est important de vérifier que
le paquet reçu est protégé conformément à la politique de sécurité en
vigueur, ce qui correspond aux étapes 4 et 5 de la figure 7. Prenons pour
exemple une passerelle IPsec défectueuse qui, au lieu de protéger le flux
de paquets IP sortant de son réseau, les envoie sans aucune protection
sur le réseau public. La passerelle IPsec réceptrice doit donc s'assurer que
la protection du paquet est bien conforme aux exigences de sécurité. Si
elle accepte ces paquets et les laisse entrer sur son réseau interne,
d'autres paquets suivront, eux aussi avec un niveau de sécurité inadéquat.
Il est donc important qu'elle rejette ces paquets pour couper court aux
échanges. En effet, le terminal à l'origine des paquets tentera à plusieurs
reprises d'émettre la même série de paquets et finira par abandonner.
4. En-tête d’authentification AH

4.1 Modes de protection

4.2 Contenu

4.3 Calcul de l’authentificateur
• L’en-tête d’authentification (AH pour Authentication Header) garantit au
récepteur du paquet IP que l’identité de son émetteur est bien celle
déclarée dans le paquet. Il permet aussi de garantir au récepteur que
personne n’a modifié le contenu d’un paquet lors de son transfert sur le
réseau. Il peut optionnellement servir à s’assurer que le paquet n’est pas
rejoué par une personne malveillante.
• Pour assurer l’ensemble de ces services, il faut adjoindre au paquet IP
émis un authentificateur dont la validité sera vérifiée par l’équipement de
sécurité récepteur. Pour éviter que les modifications apportées par le
réseau n’aboutissent, au niveau de l’équipement de sécurité récepteur, à
de nombreux rejets de paquets pourtant légitimes, l’authentificateur doit
être calculé sur les champs dont on est sûr qu’ils ne seront pas modifiés
par le réseau.

• 4.1 Modes de protection
• Suivant le mode de protection sélectionné, l’en-tête d’authentification ne
porte pas sur les mêmes champs et n’est pas positionné au même endroit.
Figure 8 - En‐tête d’authentification AH
• Pour le mode transport, comme le montre la figure 8a, l’authentificateur ne
protège que le contenu du paquet IP ainsi que les champs de l’en-tête IP qui
ne sont pas amenés à subir de modifications lors du transfert du paquet sur
le réseau. L’en-tête AH est placé entre l’en-tête IP original du paquet IP
original et le contenu du paquet.
• Pour le mode tunnel, le paquet IP original arrivant sur un équipement
tunnelier est encapsulé dans un nouveau paquet IP. La protection offerte par
l’en-tête AH porte alors sur tout le paquet IP original et sur les champs en-
tête et options du nouveau paquet (figure 8b ) qui ne sont pas modifiables
par le réseau de transit. L’en-tête AH est à placer entre l’en-tête du nouveau
paquet construit et le paquet IP original.
•  
• 4.2 Contenu
• L’en-tête AH contient entre autres (figure 9) :
• le SPI (indice des paramètres de sécurité) qui permet à l’équipement de
sécurité récepteur de retrouver, en fonction de l’adresse de l'équipement
IPsec distant, l’association de sécurité à utiliser pour vérifier la validité de
l’authentificateur ;
• l’authentificateur calculé sur le paquet IP à l’aide de l’algorithme et de la
clé de chiffrement contenus dans l’association de sécurité adéquate. Cette
association est identifiée par le SPI, l’adresse de l'équipement IPsec
distant et le protocole AH ;
• l'en-tête suivant qui renseigne sur le type de protocole qui suit l'en-tête
AH. Dans le cas du mode tunnel, comme un paquet IP est encapsulé dans
le tunnel, il s'agit du protocole IPv4 ; dans le cas du mode transport, il
s'agit classiquement du protocole TCP ou UDP.
Figure 9 - Format de l’en‐tête AH
Algorithmes utilisés dans IPsec

Algorithmes de chiffrement de Triple DES, AES, DES CBC, RC5,


données (pour ESP uniquement) IDEA

Algorithmes de génération de
HMAC MD5, HMAC SHA1
l'authentificateur (pour AH et ESP)

Algorithmes utilisés dans IPsec


• Cet en-tête contient aussi un numéro de séquence (sequence number) qui est
incrémenté à chaque paquet émis de telle sorte que l’équipement récepteur
puisse aisément détecter les paquets IP rejoués. La détection de rejeux consiste
bien souvent à vérifier la croissance stricte du numéro de séquence. La
détection de rejeux est optionnelle car l’équipement de sécurité générant l’en-
tête AH doit remplir correctement le champ numéro de séquence tandis que
l’équipement qui l’extrait n’est pas tenu de vérifier la bonne valeur de ce
champ‐là.

• 4.3 Calcul de l’authentificateur
• L’authentificateur est généré sur une partie d’un paquet IP sous la forme qu’il
aurait à la réception finale, c’est-à-dire que tous les champs susceptibles d’être
modifiés en cours de transit sur le réseau sont mis à zéro. Pour IPv4, ces champs
sont le type de service (TOS), les drapeaux, la place du fragment, la durée de vie
et le checksum (se référer à l’article Routage dans les réseaux Internet pour une
description détaillée de ces champs). Le calcul de l’authentificateur nécessite
également que le champ contenant l’authentificateur soit mis à zéro. Pour la
vérification de l’authentificateur, l’ensemble de ces champs devra être mis à
zéro.
• La liste des algorithmes disponibles dans IPsec pour générer
l'authentificateur est donnée dans le tableau 1.
• Nota :
• pour le détail des outils cryptographiques utilisés, le lecteur pourra se
reporter aux références  et , ainsi qu’à l’article [H 5 210].
5. En-tête ESP

• 5.1 Modes

5.2 Contenu

5.3 Construction

5.4 Extraction
• L’en-tête ESP (Encapsulating Security Payload) permet d’assurer la
confidentialité des paquets IP, et/ou, tout comme l’en-tête
d’authentification le fait, il permet de garantir l’intégrité des paquets et
l’identité de son émetteur. L’authentificateur permet optionnellement de
détecter les rejeux de paquets. Contrairement à AH, ESP encapsule
véritablement l'ensemble des champs à protéger, ce qui justifie le E
(Encapsulating) de ESP.

• Pour rendre l’ensemble de ces services de sécurité, il est nécessaire de


chiffrer les données à protéger, de calculer un authentificateur et
d’encapsuler ces informations dans l’en-tête ESP. Il est important de
constater ici que l’authentificateur est calculé après avoir réalisé le
chiffrement. Cela permet un gain de temps à la réception du paquet. En
effet, si le paquet est erroné, plutôt que de déchiffrer et de se rendre
compte ensuite que l’authentificateur est mauvais, l’authentificateur est
d’abord vérifié et, s’il est correct, le déchiffrement a lieu.

• Bien entendu, pour construire cet en-tête ESP, il est nécessaire qu’une
association de sécurité soit convenue entre les deux équipements
réalisant la sécurité de la communication. Cette association de sécurité
doit contenir le ou les algorithmes de chiffrement, la ou les clés et un
indice de paramètres de sécurité SPI.
• 5.1 Modes
• L’en-tête ESP est composé d’un sous-en-tête ESP, d’une queue ESP et d’un
authentificateur ESP. Suivant le mode de protection choisi, l’étendue des
champs protégés diffère.

Figure 10 - En‐tête ESP


• En mode transport, seul le contenu du paquet IP est protégé. Plus
précisément, seuls le contenu du paquet et la queue ESP sont chiffrés
(figure 10a ). L’authentificateur placé dans le champ Auth. ESP permet
d’authentifier l’équipement émetteur et de prouver l’intégrité de l’en-tête
ESP, excepté le champ Auth. ESP puisqu’il est mis à zéro lors du calcul de
l’authentificateur. Ainsi, le contenu du paquet IP est protégé. L’en-tête
ESP est placé après l’en-tête IP original, en dernière position.
• En mode tunnel, tout le paquet IP est protégé (figure 10b ). Le paquet IP
arrivant sur un équipement tunnelier est entièrement chiffré, ainsi que la
queue ESP. L’authentificateur est ensuite calculé et placé dans Auth. ESP.
Il garantit l’intégrité et l’authentification du paquet IP original et de l’en-
tête ESP (excepté le champ Auth. ESP). Le résultat du chiffrement et
l’authentificateur sont alors encapsulés dans un nouveau paquet IP qui,
lui, n’est pas protégé par l’en-tête ESP.
• 5.2 Contenu

• La figure 11 le présente en détail l’en‐tête ESP.


• Ainsi, le champ Sous-en-tête ESP comprend les champs suivants :
• le SPI permet à l’équipement de sécurité récepteur de retrouver, en
fonction de l’adresse de l'équipement IPsec émetteur, l’association de
sécurité à utiliser pour déchiffrer le paquet et/ou vérifier
l’authentificateur ;
• le numéro de séquence permet la détection de rejeux.
Figure 11 - Format de l’en‐tête ESP
• Le champ Queue ESP comprend différents champs dont le champ En-tête
suivant qui permet de préciser le contenu de ce qui est chiffré, à savoir s’il
s’agit d’un paquet IP complet (mode tunnel) ou du contenu d’un paquet IP
(mode transport).
• Le champ Auth. ESP contient l’authentificateur. Il est optionnel. Sa présence
est indiquée par l’association de sécurité utilisée identifiée ici par le triplet :
SPI, adresses de l'équipement IPsec distant et protocole ESP.
L’authentificateur est calculé sur l’ensemble de l’en-tête ESP.
• Tout comme pour l’en-tête d’authentification AH, la détection de rejeux est
optionnelle. En revanche, elle ne peut être rendue que si le numéro de
séquence est protégé par l’authentificateur.
• Notons que l’authentification et le contrôle d’intégrité réalisés par
l’authentificateur dans l’en-tête ESP ne protègent que le contenu de l’en-tête
ESP, contrairement à l’en-tête AH qui porte sur tout le paquet IP exceptés les
champs susceptibles d’être modifiés par le réseau. Dans certains cas, suivant
le niveau de protection en intégrité souhaité, il peut être nécessaire de
recourir aux deux en-têtes de sécurité pour protéger le même paquet, l’en-
tête ESP ne rendant alors que le service de confidentialité.
• 5.3 Construction
• Si d’après l‘association de sécurité, les données sont à chiffrer, ces données
sont alignées sur un multiple d’un certain nombre d’octets (défini par
l’association de sécurité). L’alignement consiste à ajouter aux informations
à chiffrer des bits non significatifs de bourrage de telle sorte que
l’algorithme de chiffrement puisse chiffrer un nombre entier de blocs de
données de taille fixe. Le nombre de bits non significatifs est préciser dans
le champ Longueur bourrage. L’ensemble de ces champs est ensuite chiffré
et placé dans l’en-tête ESP.
• Si aucun chiffrement n’est exigé, alors les informations contenues dans l’en-
tête ESP sont alignées sur un multiple de 4 octets puis placées dans l’en-
tête ESP.
• Si l’association de sécurité ne requiert pas les services
d’authentification/intégrité, l’en-tête ESP ne contient pas
d’authentificateur. Sinon, l’authentificateur est calculé sur les champs
présents dans l’en-tête ESP, c’est-à-dire tous les champs excepté
l’authentificateur lui-même.
• La liste des algorithmes disponibles est donnée dans le tableau 1.
• 5.4 Extraction
• À la réception de l’en-tête ESP, selon la valeur du champ SPI et de l’adresse de
l'équipement IPsec émetteur indiquée dans le paquet, l’association de
sécurité utilisée est identifiée. En fonction des services de sécurité requis, le
traitement diffère. Les services d’authentification/intégrité, s’ils sont présents,
seront d’abord réalisés en vérifiant que l’authentificateur reçu est correct. Le
service de confidentialité, s’il est demandé, sera ensuite traité en déchiffrant
les informations dans le champ Champs potentiellement chiffrés. Il est alors
facile de récupérer les informations déchiffrées qui sont interprétées comme
un paquet IP entier ou comme le contenu d’un paquet IP suivant le mode
utilisé. En toute rigueur, il est ensuite conseillé de vérifier la conformité de
l’association de sécurité appliquée sur le paquet avec la politique de sécurité
locale, ceci afin d’éviter par exemple que des données sensibles ne transitent
avec un niveau de sécurité insuffisant.
• Si une erreur se produit (l’authentificateur est mauvais, le service requis
n’était pas traité dans l’en-tête ESP reçu, le déchiffrement s’est mal passé,
l’association de sécurité est inadaptée), il faudrait que cet événement soit
enregistré et qu’une alarme soit générée pour que l’officier de sécurité du site
en soit averti.
• 6. IPsec appliqué au protocole IPv6
• En matière de sécurité, IPv6 offre plusieurs avantages sur IPv4. Tout d’abord,
contrairement à IPv4, le protocole IPsec est fourni dans toutes les piles IPv6.
Ainsi, toutes les machines dotées d’une pile IPv6 peuvent échanger des
informations de façon protégée sur le réseau. En revanche, une communication
établie avec un terminal IPv4 ne pourra pas nécessairement être protégée. Cela
dépendra de l’intégration ou non d’IPsec dans sa pile. Le deuxième
inconvénient d’IPv4 sur IPv6 réside dans la traduction d’adresses qui est
pratiquée dans IPv4 et qui rend l’utilisation d’IPsec difficile. Enfin, IPv6 résout le
problème de fragmentation de paquet par le biais d’un mécanisme chargé de
découvrir la taille maximale de paquet autorisée sur une communication.
• Les principes de l’IPsec ne varient pas de l’environnement IPv4 à IPv6. Les seuls
aspects modifiés sont les suivants :
• la notion d’option n’existe plus. Les en-têtes AH et ESP sont remplacés par les
extensions AH et ESP ;
• les champs modifiables qui doivent être mis à zéro lors du calcul de
l’authentificateur, dans le cas de l’en-tête AH, sont pour IPv6 les champs classe,
identificateur de flux et nombre de sauts ;
• l’en-tête AH en mode transport est placé après les extensions du paquet et
avant le contenu du paquet, avec possibilité d’avoir l’en-tête de destination
placé avant ou après l’en-tête AH. Tout comme pour IPv4, l’en-tête ESP est
positionné en dernière position. Cependant, en mode transport, IPv6
permet l’encapsulation de l’extension de destination du paquet dans la
charge utile de l’extension ESP.

• 7. Gestion des associations de sécurité


• Pour assurer la protection des communications entre deux équipements de
sécurité (terminaux et/ou passerelles de sécurité), il est nécessaire que ces
derniers partagent au moins une association de sécurité. Une gestion
manuelle est possible. Elle consiste à saisir l'ensemble des paramètres IPsec
(services de sécurité, algorithmes de chiffrement, clés de chiffrement, etc.).
Cette méthode est peu recommandée dans le cas de la gestion d'un parc
important d'équipements IPsec car elle devient vite fastidieuse. D'autre
part, pour améliorer le niveau de sécurité, il est nécessaire de renouveler
régulièrement les associations de sécurité. Pour éviter tout travail manuel
répétitif, il est intéressant de mettre en place un mode dynamique.
• Le protocole retenu par l'IETF pour assurer la gestion des associations de
sécurité dynamique s’appelle IKE (Internet Key Exchange) . Il est composé
des protocoles suivants :
• un protocole de gestion des associations de sécurité appelé ISAKMP
(Internet Security Association and Key Management Protocol)  définit des
formats de paquets permettant de créer, modifier et détruire des
associations de sécurité. Ce protocole assure l’authentification des
équipements de sécurité en cours de négociation. Il est difficile à mettre
en œuvre car particulièrement complexe et lourd. Cependant, il offre un
avantage de taille : il permet d’échanger des clés de chiffrement sans
imposer de protocole d’échange de clés particulier. Cela est rendu
possible par le caractère générique d’ISAKMP. Ainsi, si le protocole
d’échange de clés sélectionné s’avère peu fiable par la suite, il suffira de
choisir un autre protocole sans pour autant avoir à modifier le protocole
ISAKMP ;
• le protocole d’échange de clés retenu par l’IETF est basé sur les deux
protocoles SKEME (Secure Key Exchange Mechanism) et Oakley .
Figure 12 - Placement d’IPsec et du module IKE dans une pile
TCP/IP
• Comme le suggère la figure 12, le protocole IKE est un protocole de niveau
applicatif qui peut tout aussi bien servir à négocier des paramètres de
sécurité pour SSL (Secure Socket Layer) et SHTTP (Secure HTTP) que pour
IPsec. L’ensemble des paramètres à négocier pour chacun de ces
protocoles étant différent, l’IETF a défini un domaine d’interprétation
(DOI) pour chacun et en particulier un DOI IPsec.
• Les produits VPN actuels proposent deux modes permettant à deux
équipements de sécurité IPsec de s'authentifier lors de leurs échanges
ISAKMP :
• mode basé sur des secrets partagés (pre-shared key) : les équipements
sont configurés deux à deux avec une clé secrète identique. Pour
s'authentifier, un équipement devra prouver à son partenaire qu'il connaît
la clé secrète partagée. En général, cette clé est dérivée d'un mot de passe
rentré manuellement au niveau de chacun des équipements. Ce mode
souffre de plusieurs inconvénients. Outre la configuration manuelle des
mêmes mots de passe sur chaque paire d'équipements, la fonction de
dérivation est propriétaire, ce qui rend impossible l'utilisation de ce mode
entre deux équipements de constructeurs différents ;
• mode basé sur les certificats de clés publiques : chaque équipement
possède un secret appelé clé privée qui lui est propre. Pour s'authentifier,
un équipement devra prouver qu'il possède cette clé privée. Les difficultés
d'utilisation de ce mode sont décrits au paragraphe 8
• 8. Distributions des clés publiques
• L’authentification des équipements de sécurité mise en œuvre lors de la
négociation des associations de sécurité peut faire appel à la cryptographie à
clé publique où deux types de clés complémentaires interviennent :
• la clé privée n’est connue que d’un seul équipement de sécurité et permet à
cet équipement de s’authentifier ;
• la clé publique peut être diffusée sur le réseau.
• Ces clés sont complémentaires car le chiffrement avec l’une des clés
nécessite le déchiffrement avec l’autre clé. Pour qu’un équipement
s’authentifie, il lui suffit donc d'utiliser sa clé privée ; l’équipement IPsec
récepteur aura l’assurance de l’identité de son partenaire à condition qu’il
possède sa clé publique. Il est clair que toute la sécurité de la
communication entre deux équipements repose sur la fiabilité de
l'association de la clé publique et de son équipement propriétaire. Si cette
association n'est pas sûre, rien ne sert de protéger les échanges ultérieurs
avec l'équipement puisqu'il peut s'agir d'un équipement autre que celui
déclaré. La diffusion fiable des clés publiques est véritablement au cœur de
la sécurité des échanges électroniques aujourd'hui.
• Une manière de diffuser de façon sûre une clé publique est de faire
certifier par un tiers habilité un ensemble d’informations. Dans le
certificat X.509 le plus couramment utilisé aujourd’hui (voir l’article
[H 5 510]), ces informations regroupent, entre autres, l’identité de
l’équipement de sécurité (adresse IP, nom de domaine), sa clé publique,
un numéro de série et sa date de validité. Un certificat est en principe
utilisable jusqu’à sa date d’expiration. Néanmoins, suite à la
compromission d’une clé privée par exemple, il peut être révoqué avant
cette date. Dans ce cas-là, il est primordial d’avertir les utilisateurs du
certificat de son invalidité. Si plusieurs techniques de révocation sont
envisagées, aucune n’est pour l’instant répandue.
• La plupart des passerelles IPsec actuelles se chargent de générer leur biclé
(clé publique, clé privée), d'émettre une demande de certificat, d'importer
des certificats de clé publique, d'en exporter, etc. Toutes ces opérations
sont réalisées par l'échange de fichiers dans un format PKCS (Public Key
Cryptography Standard) entre les équipements IPsec et le serveur
gestionnaire de certificats.
• Exemple :
• supposons qu’une station a d’un site A veuille échanger des informations
avec une station b du site B de façon confidentielle. Supposons que les sites A
et B soient reliés par un tunnel IP et que leurs équipements tunneliers soient
dotés du protocole IPsec pour protéger le trafic, comme le suggère la
figure 4.
• La station a émet alors des paquets IP. Le tunnelier les reçoit et constate
qu’aucune association de sécurité n’a été négociée pour cette
communication entre a et b. Il décide alors de contacter son homologue du
site B pour négocier une association de sécurité par IKE .
• La négociation s’effectue en deux étapes. Tout d’abord, le tunnelier du site A
(module IKE) s’authentifie auprès du tunnelier de B (module IKE) et négocie
une première association de sécurité de niveau applicatif appelée ISAKMP.
Cette association de sécurité ISAKMP sert à protéger tous les échanges
ultérieurs entre modules IKE. En particulier, elle protège la négociation d’une
association de sécurité IPsec qui servira aux deux tunneliers à chiffrer le trafic
entre les terminaux a et b. Cette association contient l’algorithme de
chiffrement, la clé de chiffrement à utiliser, ainsi que l’identificateur SPI de
l’association de sécurité.
• Suivant les capacités mémoire du tunnelier A, le volume de trafic, etc., il
est possible que les paquets émis par la station a aient été détruits au
niveau du tunnelier A et que le terminal a soit dans l’obligation de les
réémettre. Ces paquets seront ensuite chiffrés par le tunnelier de A en
fonction de l’association de sécurité négociée, conformément à la
figure 5. Ils seront émis sur le tunnel IP à destination de B.
9. Incompatibilité entre IPsec et la
traduction d’adresses

• 9.1 Problèmes de compatibilité

9.2 Solutions préconisées
• Le principe et l’utilisation de la traduction d’adresses sont décrits dans
l’article Routage dans les réseaux Internet et dans  . En général, un
équipement est placé en frontière d’un site et se charge de traduire, pour
chaque paquet sortant sur Internet, les adresses privées du site en
adresses publiques, et vice versa pour les paquets entrants. Ces adresses
publiques sont utilisées par le réseau public pour acheminer les paquets IP
jusqu’au site. Si le nombre d'adresses publiques dont dispose un site est
insuffisant, il est possible que le traducteur d'adresses traduise également
les numéros de port, ce qui est actuellement très répandu sur les réseaux.
• De nombreux problèmes de compatibilité entre IPsec et la traduction
d’adresses/numéros de port se posent lorsque le traducteur est placé
entre deux passerelles de sécurité souhaitant protéger leurs
communications par IPsec (figure 13). Ces problèmes rendent l'utilisation
d'IPsec impossible en de nombreuses circonstances.
• Figure 13 - Équipement de traduction d’adresses placé entre deux
passerelles de sécurité
Exemple :
• il est très fréquent qu'un hôtel, une gare ou un aéroport dispose d'un traducteur
d'adresses/numéros de port sur son réseau ; les utilisateurs connectés à ce type
de réseau ne pourront pas activer le protocole IPsec et donc protéger leurs
échanges.
• On peut également remarquer que de plus en plus de fournisseurs d'accès
Internet s'équipent aussi de traducteurs car ils manquent d'adresses publiques.
Face à ce problème conséquent qui freine l'utilisation d'IPsec, l'IETF est en train
de proposer une solution. Elle est sommairement décrite dans le
paragraphe 9.2.

• 9.1 Problèmes de compatibilité
• L'incompatibilité entre le protocole AH et la traduction d'adresses seule est
particulièrement facile à mettre en évidence. En effet, l’authentificateur de l’en-
tête AH est calculé sur les adresses IP des paquets car elles ne sont pas
considérées comme modifiables par IPsec. Comme le traducteur d’adresses
modifie l’adresse source des paquets IP sortant du site, l’authentificateur reçu
par l’équipement de sécurité du site distant est invalide et le paquet est rejeté.
• De la même façon, les paquets IP circulant dans l’autre sens (du site B vers
le site A) sont rejetés car l’adresse de destination est traduite. Une solution
serait de décaler la passerelle de sécurité du site A de l’autre côté du
traducteur d’adresses de telle sorte que les deux passerelles de sécurité
soient placées en vis‐à‐vis. Mais elle n’est pas réalisable dans le cas où le
protocole IPsec est intégré au niveau du terminal du site A : il peut
classiquement s'agir d'un nomade qui désire se connecter depuis un
aéroport à son réseau d'entreprise via un VPN IPsec.
• Le protocole ESP (dans le mode transport) souffre aussi d'incompatibilités
avec la traduction d'adresses seule, bien que l'authentification réalisée par
ESP ne porte que sur le contenu de l'en-tête ESP. En effet, les protocoles
TCP et UDP définissent un champ de contrôle dont le calcul fait intervenir
les adresses IP. Ainsi, la modification d'une adresse suppose la modification
de ce contrôle, ce qui n'est pas réalisable avec ESP en mode transport. En
effet, soit le chiffrement est activé dans ESP et le champ de contrôle est
inaccessible car chiffré, soit les services d'authentification/intégrité sont
activés, et la modification du champ de contrôle conduira à la détection
d'un problème d'intégrité du paquet et au rejet du paquet par la passerelle
de sécurité réceptrice.
• Le fait de traduire également les numéros de port ajoute encore
davantage d'incompatibilités. Pour ESP, c'est l'encapsulation elle‐même
qui pose problème car elle rend les numéros de port soit inaccessibles
(chiffrement activé), soit interdits de modification (car protégés en
intégrité). Enfin, notons que pour ESP en mode tunnel, les numéros de
port sont inexistants.
• Un autre problème se pose lorsque deux passerelles IPsec établissent
dynamiquement une association de sécurité. Lors de l'établissement de
cette association de sécurité, les passerelles doivent s'authentifier. La
plupart du temps, elles s'identifient par le biais de leurs adresses IPv4. Si
l'équipement de traduction d'adresses vient à modifier l'adresse des
paquets, il y aura incohérence entre l'adresse servant à identifier la
passerelle et l'adresse d'origine des paquets reçus. Les paquets seront
donc rejetés par la passerelle réceptrice. Une solution consisterait ici à
utiliser un identifiant pour les passerelles différent des adresses, comme
un nom de type passerelle.entreprise.com, mais même cette solution
n'est pas satisfaisante du fait qu'une politique de sécurité s'exprime à
l'aide des adresses.
• 9.2 Solutions préconisées
• Dans le cas d'une entreprise ayant besoin des services de traduction
d'adresses et de VPN (par IPsec), il lui est conseillé de s'équiper d'un seul
équipement fournissant ces deux services. De nombreux produits
commerciaux proposent ces deux types de services. Il sera alors possible
de jouer sur l'ordre d'application de ces services afin d'éviter les
problèmes d'incompatibilité mentionnés précédemment. Plus
précisément, les paquets sortant d'un réseau privé devront tout d'abord
être traduits avant d'être protégés par IPsec puis émis sur le réseau
public.
• Dans le cas où la traduction d'adresses et le service VPN ne peuvent
fusionner (par exemple, l'utilisateur est en déplacement et se connecte
depuis son ordinateur portable à un réseau quelconque mettant en œuvre
de la traduction d'adresses), la solution consiste à n'utiliser que le
protocole ESP (mode transport ou tunnel) et à réaliser une encapsulation
UDP supplémentaire . Plus précisément, un tunnel UDP est établi entre le
portable de l'utilisateur et sa passerelle IPsec ; les données échangées
dans ce tunnel sont protégées par le protocole ESP.
• Ainsi, comme l'indique la figure 14, la traduction des adresses/numéros de
port donne lieu à la modification du champ de contrôle d’UDP sans porter
atteinte à l'intégrité de l'en-tête ESP et la traduction de numéros de port
est faite sur les numéros de port UDP qui sont accessibles ici.
• Pour répondre au problème de l'établissement dynamique d'une
association de sécurité et pour basculer dans le mode d'encapsulation
UDP, il est nécessaire que les passerelles IPsec détectent la traversée d'un
équipement de traduction. Cette détection se fait en ajoutant dans le
protocole IKE 7 un champ NAT_D (NAT Discovery) contenant un contrôle
d'intégrité portant sur les adresses IP des paquets et les numéros de port.
Ainsi, en cas de traversée d'un traducteur, le contrôle d'intégrité ne
correspondra plus aux adresses/numéros de port reçus dans le paquet et
les passerelles devront alors adapter leur comportement. Elles devront par
exemple accepter que des paquets soient reçus avec une adresse IP
différente de celle déclarée lors de la phase d'authentification. Outre
l'encapsulation UDP à réaliser, elles devront émettre périodiquement des
messages NAT-keepalive afin de maintenir dans l'équipement de
traduction la table de correspondance entre les adresses publiques/privées
et les numéros de port publics/privés.
Figure 14 - Encapsulation UDP : solution au problème de la
traduction d’adresses / numéros de port
• 10. Autres problèmes liés à l’utilisation d’IPsec
• Du fait que le protocole IPsec peut accroître de façon considérable la taille
des paquets IP (environ 50 octets ajoutés par l’en-tête ESP), il est possible
que la taille résultante dépasse la taille maximale autorisée sur un lien de
réseau et provoque la fragmentation des paquets. À la réception,
l’équipement de sécurité doit alors réassembler les paquets avant de les
traiter. Cette opération de réassemblage, qui fait appel à la
« bufferisation » des paquets, peut conduire à des pertes de paquets et à
des chutes de débit d’autant plus importantes que le trafic est dense.
L’une des possibilités est d’interdire à la source toute fragmentation des
paquets de telle sorte que la source soit avertie qu’elle doit prévoir des
paquets de taille réduite.
• Le protocole DHCP permet d’optimiser un espace d’adressage géré par
une entreprise en attribuant, à la demande, une adresse IP à un terminal.
De ce fait, une adresse IP n’est plus associée à un terminal particulier et il
n’est plus possible pour un équipement de sécurité de sélectionner une
association de sécurité en fonction de la seule adresse IP de l’émetteur ou
du destinataire, comme le prévoit Ipsec.
• 11. Évolutions d'IPsec
• Pour faciliter le travail des constructeurs et converger vers des produits
VPN interopérables, la tendance est à la simplification des protocoles liés
à IPsec. Ainsi, le protocole AH va prochainement devenir optionnel et les
implémentations d'IPsec s'en trouveront allégées.
• Nota :
• actuellement, toute implémentation qui se veut conforme à IPsec doit
obligatoirement intégrer les protocoles AH et ESP.
• Une nouvelle version d’IKE (IKEv2) devrait être disponible en 2003.
Contrairement à IKE où de nombreux documents (ISAKMP, DOI, IKE...)
sont utilisés pour spécifier le protocole IKE avec de nombreuses
incohérences, des difficultés de lecture, etc., IKEv2 sera décrit dans un
seul document et sera exclusivement utilisé dans un contexte IPsec. Il
perdra donc son caractère générique et sera ainsi plus léger.
• 12. Alternatives à IPsec
• Les solutions SHTTP et SSL sont apparues dans les années 1990 dans
l’intention de favoriser le déploiement du commerce électronique. SHTTP
fut développé par le consortium CommerceNet et consiste à introduire les
services de confidentialité, intégrité et authentification dans le protocole
HTTP.
• La solution SSL  fut développée par Netscape Communications en réponse à
SHTTP. Elle supplanta SHTTP du fait de sa gratuité et parce qu’elle fut
rapidement intégrée dans les navigateurs web grand public tels que
Netscape Navigator et Internet Explorer. SSL se présente sous la forme d’une
couche protocolaire à placer entre la couche TCP et les applications basées
sur TCP. SSL permet donc de protéger tout le trafic issu des applications
telnet, HTTP, FTP, etc. Ces applications protégées par SSL sont alors appelées
HTTPS, telnets, FTPS et sont identifiées par un numéro de port particulier. La
version SSLv3.0 de 1996 intégrée dans Netscape Navigator 3.0 et Microsoft
Internet Explorer 3.0 permet au serveur web et à l’utilisateur de
s’authentifier et de protéger le trafic de données en assurant les services de
confidentialité, intégrité, authentification et détection de rejeux.
• les échanges TCP, IPsec assure la protection de l’ Contrairement à SHTTP
qui ne protège que le trafic HTTP et SSLensemble du trafic IP, aussi bien
les paquets TCP que les paquets UDP. De cette façon, IPsec convient à un
plus grand nombre d’applications. Une autre différence capitale est que
les solutions SSL et SHTTP sont intégrées sous forme logicielle au niveau
d’équipements terminaux tandis qu’IPsec s’intègre dans les routeurs ou
dans les terminaux. SSL et SHTTP apparaissent donc adaptées pour une
protection de bout en bout entre client et serveur tandis qu’IPsec est idéal
pour protéger de façon systématique des échanges entre sites distants.
• 13. Conclusion
• Cet article présente les protocoles IPsec qui permettent d'assurer la
protection des données échangées sur le réseau en introduisant dans les
paquets IP des en-têtes de sécurité permettant de transporter
l’authentificateur de l’émetteur, de chiffrer le contenu des paquets IP, etc.
• La technologie IPsec est largement intégrée dans les services de réseaux
privés virtuels (VPN) pour protéger les échanges entre sites distants. La
solution consiste à configurer un tunnel IP entre chaque couple de sites du
VPN et à assurer les services de confidentialité, authentification et intégrité
par le biais d'IPsec.
• Tous les paquets IP arrivant à l’entrée du site émetteur sont pris en charge
par un équipement tunnelier qui ajoute les en-têtes de sécurité appropriés
et les encapsule dans de nouveaux paquets IP. L’équipement tunnelier du
site destinataire n’a plus qu’à faire l’opération inverse, récupérer les paquets
originaux, vérifier la validité des en-têtes de sécurité et, si besoin est,
déchiffrer les paquets. La plupart des entreprises étant munies de pare-feu,
il est primordial que l’équipement tunnelier soit placé entre le pare-feu et le
réseau public de telle sorte que le filtrage soit réalisé sur des paquets IP non
chiffrés.