créateur de convergence
  • Google
  • Linkedin
  • Twitter
  • Youtube
  • Rss
  • Accueil
  • Infos
    • Emploi
    • Evènements
    • News
  • Formations
    • ACR Centre
    • ACR Distribution Est
    • Dreamtech PACA
    • HBP Rhône-Alpes
    • Immotique Distribution Nord
    • Indis Réseaux IDF
    • Primo IDF
    • Renest Ouest
    • Sodecpa Sud-Ouest
  • Nouveau Produit
    • Câbling
    • Data
    • DECT
    • Energie
    • Impression
    • Péritéléphonie
    • Sonorisation
    • Téléphonie
    • Triple Play / DSLAM
    • Vidéosurveillance
    • Visioconférence
    • VoIP
    • Wifi
  • Outils
  • PCIS
  • Promotions
    • Aastra
    • Alcatel-Lucent
    • Dlink
    • Dymo
    • Fluke Networks
    • GN-Jabra
    • Nexans
    • Panasonic
    • Plantronics
    • ZyXEL
  • Tarif & Catalogue
  • Agenda
Accueil» Glossaire Réseaux et Télécoms » IPv6 – La Sécurité dans IPv6

IPv6 – La Sécurité dans IPv6

IPv6 – La Sécurité dans IPv6 – [RFC 1752] – Dans le domaine de la sécurité, IPv6 doit arriver à rendre deux
services :

  • Intégrer un système d’authentification de l’utilisateur et garantir l’intégrité des données.
  • Offrir un système de cryptage applicable soit à la totalité du datagramme IP, soit à l’unité des données du

niveau 4 transport.
Ces systèmes doivent être suffisamment décorrélés des algorithmes employés, afin que l’armée ou
l’industrie puisse les mettre en oeuvre facilement.
Il semble que les groupes de travail se soient accordés sur un certain nombre de points tels que la
séparation du moyen d’authentification de celui du cryptage des informations. Une infrastructure de gestion
des clés est requise afin de rendre possible l’utilisation d’en-têtes d’authentification et de cryptage.
Cependant, cet aspect n’est pas encore réellement au point d’autant plus que l’effet pervers de ces
techniques de sécurité est l’ajout de coûts supplémentaires et la baisse des performances du système.
Quelques définitions :

  • L’authentification : Elle permet de savoir si la donnée reçue est la même que celle envoyée et, de la
  • L’intégrité : Elle assure la bonne transmission de la donnée, de sa source à sa destination sans aucune
  • La confidentialité : Elle garde les communications confidentielles afin que seuls les participants puissent
  • Le cryptage : Il s’agit d’un mécanisme communément utilisé pour permettre la confidentialité des

même façon, si le demandeur désiré est bien identifié.
altération intermédiaire.
identifier ce qui a bien été envoyé.
informations.

  • SAID : ou encore <<Security Association IDentifier>>
  • Security Association : L’ensemble des informations de sécurité relatives à la connexion d’un réseau donné

ou à un ensemble de connexions ; ce qui inclue des clés de cryptage, des clés de durée de vie, des
algorithmes, des degrés de sensibilité (non-classé, secret, propriétaire), mais aussi des services de sécurité
(authentication-only, Transport-Mode Encryption, IP-Mode Encryption) ou toutes les autres possibilités
envisageables.

  • L’analyse du trafic : Elle correspond à une sorte d’attaque du réseau où l’adversaire est capable de faire

des déductions sur le réseau lui-même grâce à l’analyse des données repérées sur le trafic (telles que la
fréquence de transmission, qui parle à qui, la taille des paquets, le Flow IDentifier utilisé, etc.).
Les mécanismes de sécurité dans IPv6
Le premier objectif est d’obtenir des mécanismes de sécurité sûrs et disponibles pour tous les utilisateurs qui
le désirent. Les algorithmes développés pour ces fonctionnalités ne doivent, bien entendu, pas affecter les
autres aspects de l’implémentation IP.
Il existe deux mécanismes de sécurité dans IPv6. Le premier est le mécanisme de l’en-tête d’authentification
(Authentication Header), le second, une technique d’encapsulation affectée à la sécurité appelée ESP
(Encapsulating Security Payload) permettant l’intégrité, l’authentification et la confidentialité. Cependant, les

mécanismes de sécurité IPv6 ne sont pas efficaces face à des attaques de type analyse du trafic, pour le
moment.

  • Le mécanisme de l’en-tête d’authentification (Authentication Header). L’en-tête d’authentification IPv6

cherche à rendre possibles l’intégrité et l’authentification des datagrammes IPv6. Ceci est obtenu par la
mise en place d’une fonction d’authentification du cryptage sur le datagramme IPv6 ainsi que l’utilisation
d’une clé secrète d’authentification. L’utilisateur qui émet inclut des données d’authentification dans les
paquets IPv6 à traiter ; quant à l’usager qui les reçoit, il vérifie la justesse des données d’authentification.
Certains champs de l’en-tête, qui évoluent lors de la transition (cas du champ Hop Limit), sont omis lors de
l’authentification. Cependant, cette omission n’a pas de véritables conséquences sur la sécurité elle-même.
La non-répudiation peut devenir nécessaire pour certains algorithmes d’authentification utilisant l’en-tête
d’authentification (par exemple, les algorithmes asymétriques lorsque les clés de l’émetteur et du récepteur
sont utilisées lors de la procédure de calcul de l’authentification). La confidentialité et la protection de
l’analyse du trafic ne sont pas traitées par le mécanisme de l’en-tête d’authentification. Ainsi, les
informations d’authentification sont analysées à partir des champs du datagramme IPv6 qui n’évoluent pas
durant son transfert de la source à la destination. Tous les éléments (en-têtes, données, etc.) sont intégrés
à l’analyse. La seule exception concerne certains champs comme le <<Hop Count>> (en-tête IPv6) ou la
<<Next Address>> (en-tête de routage IPv6) qui sont omis.
En outre, il est fort probable que le mécanisme de l’en-tête d’authentification risque d’accroître les coûts du
processus IPv6 ainsi que l’attente de la communication.
Enfin, le mécanisme de l’en-tête d’authentification apporte une véritable sécurité dans l’Internet sans affecter
l’exportabilité des données ni augmenter trop significativement les coûts d’implémentation. Il est, bien
entendu, fortement recommandé d’utiliser ce mécanisme de sécurité de l’origine à la destination finale.
Toutes les stations de travail IPv6-only doivent implémenter la technique de l’en-tête d’authentification avec
au minimum l’algorithme MD5 utilisant une clé de 128 bits sachant que d’autres algorithmes pourront être
implémentés.

  • La technique ESP (Encapsulating Security Payload ou l’en-tête de confidentialité) pour IPv6 permet

d’apporter l’intégrité, l’authentification et la confidentialité dans les datagrammes IPv6. Ceci s’obtient soit par
l’encapsulation d’un datagramme IPv6 dans son intégralité, soit par le cryptage de la majorité des
composants ESP au niveau de l’en-tête IPv6 sachant que la partie non codée de l’en-tête est utilisée afin de
transporter les données protégées à travers le réseau. Le destinataire du datagramme enlève, se
débarrasse de l’en-tête et des options IPv6 non codées, décrypte les éléments ESP, traite puis retire les entêtes
ESP ; enfin, il obtient le datagramme IPv6 d’origine décodé ou la donnée de spécification normale du
protocole IPv6.
o Description des modèles ESP
Il existe deux modèles ESP. Le premier, connu comme un modèle IP (IP-mode), encapsule le datagramme
IP au sein de l’en-tête ESP. Le second modèle ou Transport-mode, encapsule généralement une structure
UDP ou TCP dans IP et non l’en-tête IPv6.
o Utilisation d’ESP
ESP évolue soit entre deux stations de travail, soit entre une station et un Gateway (passerelle) de sécurité,
soit encore entre deux gateways de sécurité. Les gateways de sécurité permettent à des réseaux
correctement reliés à ces derniers de ne pas se préoccuper du cryptage et d’éviter ainsi l’accroissement des
coûts monétaires et la baisse des performances dus au cryptage tout en bénéficiant de la fonction de
confidentialité.
Lorsque les stations de travail implémentent directement ESP sans l’intermédiaire des gateways de sécurité,
il leur est alors possible d’utiliser le Transport-mode. Ce mode réduit à la fois la largeur de bande
consommée et le coût du protocole pour l’utilisateur qui n’a pas besoin de garder confidentielle l’intégralité du
datagramme IPv6.
o Les impacts d’ESP sur la performance
Le mécanisme ESP a des impacts notables sur les performances du réseau. En effet, la mise en oeuvre du
protocole s’avère plus complexe si la technique ESP est utilisée dans la mesure où elle requiert davantage
de temps et de puissance de la part processus. L’accroissement du retard est dû au cryptage et au
décryptage de chaque datagramme IPv6 contenant ESP. Les conséquences relatives au coût sont variables
selon les spécificités de l’implémentation telles que l’algorithme de cryptage utilisé, la taille de la clé, etc.
Pour ces deux raisons, il est probable que les utilisateurs préféreront utiliser le mécanisme de l’en-tête
d’authentification (Header Authentication) à la place de la technique ESP.
En outre, afin d’assurer l’interopérabilité au sein du monde Internet, toutes les implémentations ESP pour
IPv6 doivent accepter l’utilisation de Data Encryption Standard (DES) dans le mode Clipher-Block Chaining
(CBC) ; cependant, d’autres modes et algorithmes peuvent être rajoutés.

  • La combinaison des mécanismes de sécurité

Il est possible de combiner à la fois les mécanismes Authentication Header IPv6 et ESP pour IPv6 afin

d’obtenir le niveau de sécurité désiré. La technique de l’en-tête d’authentification permet toujours l’intégrité et
l’authentification ainsi que la non-répudiation en utilisant certains algorithmes (RSA). Le mécanisme ESP
fournit toujours l’intégrité et la confidentialité mais aussi l’authentification via des algorithmes spécifiques de
cryptage. Ainsi, le mélange des deux mécanismes permet de profiter véritablement de tous les éléments de
sécurité : intégrité, authentification, non-répudiation et confidentialité.
D’autres mécanismes de sécurité permettent aussi de se protéger contre l’analyse de trafic, il faut les
implémenter au niveau de la couche IP.
La gestion des clés (Key Management) :
Le protocole de gestion des clés couplé à d’autres mécanismes de sécurité via SAID peut être utilisé pour
IPv6. IPv6 n’est pas destiné à fournir une gestion des clés de type <<in-band>>, où les données de gestion
des clés sont portées par un en-tête IPv6 spécifique. En revanche, IPv6 utilisera dans un premier temps une
gestion des clés de type <<out-of-band>> où les données de gestion des clés sont portées par un protocole
de couche supérieure tel que UDP ou TCP sur un numéro de port spécifique. De manière générale, ceci
permet le découpage du mécanisme de gestion des clés pour d’autres systèmes de sécurité ainsi que la
substitution de nouvelles méthodes de gestion des clés (à la place des anciennes) sans avoir à modifier tous
les autres outils de sécurité.

  • La distribution d’une clé manuelle

La forme la plus simple de gestion des clés est la gestion manuelle des clés où un individu configure
manuellement chaque système avec sa propre clé mais aussi les clés des autres systèmes de
communication. Ceci s’avère relativement pratique dans un environnement statique et de petite taille. En
prenant l’exemple d’un environnement réseau de type LAN, au sein d’un simple domaine administratif, il est
pratique de configurer les clés de chaque routeur de telle sorte que les données routées puissent être
protégées et qu’il soit possible de réduire le risque d’intrusions étrangères au sein d’un routeur. Cependant,
ce n’est pas une approche viable à moyen ou long terme.

  • La distribution d’une clé automatique

Le déploiement et l’utilisation des fonctions de sécurité dans IPv6 nécessitent un protocole de gestion des
clés au standard Internet. A l’origine, un tel protocole devait proposer une gamme de services dans le monde
Internet et pas seulement se réserver à la sécurité dans IPv6. Il existe des travaux en cours afin d’ajouter
des clés signées sur des stations de travail via DNS ; les clés DNS permettant d’authentifier les messages
de gestion des clés par rapport aux autres éléments de la gestion des clés utilisant un algorithme
asymétrique.
Enfin, il convient de signaler qu’une <<Multicast Key Distribution>> est en cours d’élaboration pour IPv6.
A l’heure actuelle, de nombreux travaux sur IPv6 sont en cours d’élaboration, il faut signaler la présence de
trois notions présentes dans IPv6 et pour lesquelles leur normalisation et admission définitives ne font aucun
doute, à savoir : Authentication Header, Encapsulating Security Payload, Key Management.
L’utilisation des mécanismes de sécurité dans IPv6
Cet aspect sur la sécurité a pour principal objectif de donner un aperçu des différents mécanismes assurant
la réduction des risques dans IPv6.

  • Les Firewalls.

Les Firewalls, absents dans la version actuelle d’Internet mais utilisés dans IPv6, vont permettre de corriger
les suites d’en-têtes et de déterminer le protocole de transport (UDP ou TCP) ainsi que le numéro de port de
ce protocole. La performance des Firewalls dans IPv6 ne devrait pas en être trop affectée dans la mesure où
le format des en-têtes IPv6 facilite la procédure de correction.
Les Firewalls utilisent le mécanisme de l’Authentication Header pour s’assurer l’authentification et la justesse
des données utilisées pour les décisions de contrôle d’accès à savoir la source, la destination, le protocole
de transport, le numéro de port. Cette authentification est impossible dans IPv4.
Les organisations disposant de plusieurs sites interconnectés utilisant les services commerciaux proposés
par IP peuvent sélectionner un Firewall crypté. Par exemple, si un Firewall crypté est placé entre la Société
A et le fournisseur du service commercial IP, le Firewall fournit alors un tunnel crypté au sein de tous les
sites de la Société A. Il lui est ainsi possible de crypter tout le trafic entre elle et ses fournisseurs, ses clients
ou des tiers. Une telle pratique permet de protéger facilement le trafic d’un grand nombre d’organisations de
type gouvernemental par exemple qui peuvent même mettre en oeuvre un mécanisme de fully encrypting
Firewall autorisant aussi bien un filtrage du trafic décrypté qu’un cryptage des paquets IP.

  • La protection de la Qualité de Service (QoS)

Le mécanisme de l’Authentication Header, utilisé avec la méthode de gestion des clés appropriée, permet
d’authentifier les paquets. Le champ Flow Identifier dans IPv6 peut agir comme un Low-Level Identifier
(LLID) ; par conséquent, la classification du paquet au sein des routeurs devient simple si le routeur est
fourni avec la clé appropriée. Pour des raisons de performance, les routeurs authentifient des groupes de
paquets.

Ainsi, la qualité de service fournie est obtenue par l’utilisation du champ Flow ID conjointe à celle d’un
protocole de réservation de ressources (tel que RSVP). Ainsi, la classification des paquets authentifiés
s’obtient en s’assurant que chaque paquet reçoive bien la manipulation appropriée et correcte au sein des
routeurs concernés.

  • Des réseaux compartimentés ou à niveau multiple (Multi-level)

Un réseau multi-level secure (MLS) est un réseau unique utilisé pour communiquer des données selon
différents degrés (non-classifié ou secret). De nombreux gouvernements trouvent beaucoup d’intérêt dans
l’architecture réseau MLS. IPv6 devrait supporter ce type de structure. MLS nécessite l’utilisation des
Mandatory Access Controls (MAC) que des utilisateurs normaux sont incapables de contrôler ou de violer.
Le mécanisme de l’Authentication Header peut être utilisé aussi bien pour authentifier plusieurs stations de
travail dans un niveau unique du réseau que pour garantir les décisions MAC dans un réseau à niveau
multiple. Si les étiquettes IP sont utilisées et la confidentialité considérée comme non obligatoire au sein d’un
environnement opérationnel particulier, le mécanisme de l’Authentication Header permet l’authentification du
paquet dans son intégralité, incluant un cryptage obligatoire du degré de sensibilité (non-classifié ou secret)
de l’en-tête IPv6 et des données de l’utilisateur.
La technique ESP peut être combinée avec des politiques de clé appropriées pour garantir un réseau multilevel
secure complet ainsi qu’un ensemble d’algorithmes appropriés. Dans ce cas, chaque clé doit être
utilisée pour un degré de sensibilité et un compartiment précis. Par exemple, la clé A peut être utilisée pour
des paquets non-classifiés ; la clé B, pour des paquets secrets pour un trafic sans compartiment, etc.
Le cryptage est une technique très pratique et souhaitable même dans un environnement bien protégé.
L’algorithme de cryptage au standard Internet devrait être utilisable via une gestion des clés appropriée, afin
de fournir de véritables Discretionary Access Controls (DAC) corrélés au degré de sensibilité des étiquettes,
au-delà des seules possibilités MAC offertes pour le moment.
Le développement d’un mécanisme de cryptage complet devrait être disponible pour toutes les
communications futures.
La prise en compte des autres éléments relatifs à la sécurité :
De manière générale, il faut retenir que la qualité de service fournie par les nouveaux mécanismes
développés dans IPv6 dépend totalement de l’efficacité des algorithmes de cryptage implémentés, de la
justesse de l’implémentation de ces algorithmes, des clés à utiliser, de la sécurité du protocole de gestion
des clés, de l’implémentation d’IPv6 et particulièrement de ses mécanismes de sécurité.
En outre, certains aspects propres à la sécurité (comme la protection contre l’analyse du trafic) ne sont pas
encore fournis par les mécaniques abordées précédemment. L’utilisateur doit donc faire preuve d’une
extrême vigilance.
Enfin, quelques applications (comme le courrier électronique) nécessitent des applications de protections et
de sécurités spécifiques qui ne sont pas du ressort des techniques de sécurité propres à IPv6 mais pour
lesquels des RFC seront entièrement consacrées.

Nos partenaires

Prochains évènements

   mai  2012 »
LMaMeJVSD
 123456
78910111213
14151617181920
212223
  • Renest : Formation technique AASTRA 400 CPU
    Début: 09:00
    Fin: 24 mai 2012 - 18:00
    Lieu: RENEST - Agence de Nantes
    Détails: Mise en service et exploitation des applicatifs embarqués sur la Carte CPU2 de l’Aastra 400.
    http://www.createurdeconvergence.com/renest-formation-technique-a400-cpu2/
  • formation Technique Expert Certifiante LifeSize
    Début: 10:00
    Fin: 26 mai 2012 - 17:00
    Lieu: Bureau LifeSize à Paris la Défense
24
  • Renest : Formation technique AASTRA 400 CPU
    Début: 09:00
    Fin: 24 mai 2012 - 18:00
    Lieu: RENEST - Agence de Nantes
    Détails: Mise en service et exploitation des applicatifs embarqués sur la Carte CPU2 de l’Aastra 400.
    http://www.createurdeconvergence.com/renest-formation-technique-a400-cpu2/
  • formation Technique Expert Certifiante LifeSize
    Début: 10:00
    Fin: 26 mai 2012 - 17:00
    Lieu: Bureau LifeSize à Paris la Défense
  • HBP associés : Formation commerciale AASTRA 400 R2.0
    Début: 09:00
    Fin: 24 mai 2012 - 16:30
    Lieu: HBPassociés - Agence de Lyon
    Détails: L’agence HBP associés vous propose de participer à une formation Aastra 400 R2.0, Le Jeudi 24 mai à Lyon – chez HBP
    http://www.createurdeconvergence.com/formation-commerciale-aastra-400-r2-0-4/
25
  • formation Technique Expert Certifiante LifeSize
    Début: 10:00
    Fin: 26 mai 2012 - 17:00
    Lieu: Bureau LifeSize à Paris la Défense
26
  • formation Technique Expert Certifiante LifeSize
    Début: 10:00
    Fin: 26 mai 2012 - 17:00
    Lieu: Bureau LifeSize à Paris la Défense
27
2829
  • SODECPA - Formation commerciale AASTRA 400 R2.0
    Début: 09:00
    Fin: 29 mai 2012 - 16:30
    Lieu: SODECPA - Agence de Toulouse
    Détails: L’agence sodecpa vous propose de participer à une formation Aastra 400 R2.0, Le mardi 29 mai à Toulouse ou le jeudi 31 mai à Bordeaux – chez Sodecpa
    http://www.createurdeconvergence.com/formation-commerciale-aastra-400-r2-0-5/
30
  • ACR distribution : Formation Technique FIBRE
    Début: 09:00
    Fin: 31 mai 2012 - 17:00
    Lieu: ACR DISTRIBUTION - Agence de strasbourg
    Détails: Participer à une formation technique FIBRE. Les 30 et 31 mai 2012 , de 09H00 à 17h30 chez ACR DISTRIBUTION.
    http://www.createurdeconvergence.com/formation-technique-fibre/
  • Indis Réseaux & Primo : Formation technique AASTRA 400 CPU
    Début: 09:00
    Fin: 1 juin 2012 - 17:00
    Lieu: Aastra à GUYANCOURT
    Détails: Mise en service et exploitation des applicatifs embarqués sur la Carte CPU2 de l’Aastra 400.
    http://www.createurdeconvergence.com/primo-formation-technique-a400-cpu2/
31
  • ACR distribution : Formation Technique FIBRE
    Début: 09:00
    Fin: 31 mai 2012 - 17:00
    Lieu: ACR DISTRIBUTION - Agence de strasbourg
    Détails: Participer à une formation technique FIBRE. Les 30 et 31 mai 2012 , de 09H00 à 17h30 chez ACR DISTRIBUTION.
    http://www.createurdeconvergence.com/formation-technique-fibre/
  • Indis Réseaux & Primo : Formation technique AASTRA 400 CPU
    Début: 09:00
    Fin: 1 juin 2012 - 17:00
    Lieu: Aastra à GUYANCOURT
    Détails: Mise en service et exploitation des applicatifs embarqués sur la Carte CPU2 de l’Aastra 400.
    http://www.createurdeconvergence.com/primo-formation-technique-a400-cpu2/
  • SODECPA : Formation commerciale AASTRA 400 R2.0
    Début: 09:00
    Fin: 31 mai 2012 - 16:30
    Lieu: SODECPA - Agence de Bordeaux
    Détails: L’agence sodecpa vous propose de participer à une formation Aastra 400 R2.0, Le mardi 29 mai à Toulouse ou le jeudi 31 mai à Bordeaux – chez Sodecpa
    http://www.createurdeconvergence.com/formation-commerciale-aastra-400-r2-0-5/
 

Recherche par technologie

3G Audio Baies Câbling Conférence CTI Data Datacenter DECT Domotique Energie Fax Fibre optique Firewall Hotspot Interphonie IPBX IPTV Micro Microcasque Onduleurs PABX PoE RJ45 Sécurité SIP Softphone Sonorisation Switch Téléphone Téléphonie VDI Vidéosurveillance Visioconférence VoIP Wifi

En savoir plus

  • Les agences du Réseau Alliance-Com
  • Les partenaires du Réseau Alliance-Com
  • Plan du site
  • Qui est le Réseau Alliance-Com

Derniers Tweets

  • Les oreillettes Bluetooth testées en situation extrème http://t.co/r4lhZEwP
    23 mai 2012 - 13:39
  • Alcatel-Lucent soutient la performance des Data Center http://t.co/rjTmz8Pj
    10 mai 2012 - 14:32

Les articles les plus consultés

  • Alcatel-Lucent : Tutoriaux de démarrage OS6250 / 6400 / 6850
  • Aastra Plan
  • Tarif MPLC Technologies 2012
  • Pieuvre de raccordement de PABX sur module
  • Présentation commerciale Aastra 800
  • Catalogue Audio Professionnel Bosch 2010
  • My IC Phone Alcatel-Lucent OmniTouch 8082
(c) 2012 créateur de convergence un site du Réseau Alliance-Com