Sécurité D'IPV6

Rita Pumanová

Sécurité d'IPv6

Sécurité d'IPv6

Théorie

IPv6 est un protocole IP de nouvelle génération à côté duquel on ne peut pas passer avec indifférence. On ressent de plus en plus souvent la pression de commencer à l'utiliser. Ce n'est pas étonnant car IPv6 possède beaucoup d'avantages par rapport à son prédécesseur. Ce protocole a non seulement un espace d'adresses plus large, mais aussi implémente le support pour les solutions sans fil, les applications distribuées et la sécurité. C'est un protocole idéal pour Internet en développement continu.

Cet article explique...

comment évaluer les propriétés d'IPv6 et les profits liés à son utilisation,
s'il faut l'utiliser,
quels sont les principaux dangers d'IPv6 et quels moyens de défense on peut appliquer.

Ce qu'il faut savoir...

les notions de base de TCP/IP, notamment l'adressage IPv4 (éventuellement IPv6),
la sécurité dans les réseaux IP, surtout IPSec.

Bien que la plupart des systèmes d'exploitation d'aujourd'hui et des périphériques réseau supportent déjà IPv6 (Internet Protocol version 6), l'utilisation de ce protocole dans les réseaux n'est pas encore universelle. Cette situation est due aux plusieurs facteurs. Ce sont avant tout les coûts liés au passage d'IPv4 à IPv6 et le fait que les utilisateurs ne se rendent pas compte des avantages apportés par ce dernier. Le présent article est consacré à la sécurité intégrée, l'un des principaux avantages d'IPv6 par rapport à son prédécesseur IPv4. Nous comparerons aussi les deux protocoles en ce qui concerne la sécurité de la communication en tenant compte des failles de sécurité.

Sécurité dans IPv4

La sécurité dans IPv4, de même que dans IPv6, sont en développement permanent ce les exposent à un certain risque. Certaines questions, telles que la sécurité des applications mobiles ou multidiffusion (multicast) ne seront pas analysées car le sujet est trop large. Par contre, vous allez voir que la sécurité n'est qu'un des avantages dont nous bénéficierons après le passage au protocole de nouvelle génération. IPv6 offre des adresses uniques aux différents périphériques et senseurs. Il permet aussi la mobilité et une communication peer-to-peer effective.

La sécurité dans IPv6 est similaire à celle dans IPv4. C'est une nouvelle bonne et mauvaise à la fois. Tout d'abord, grâce à la protection réseau, nous voulons savoir qui nous envoie des messages, qui lit les messages que nous renvoyons et que les messages ne sont pas modifiés lors de la communication. De plus, il est nécessaire que le réseau soit opérationnel et accessible à tous les utilisateurs autorisés et que nous ayons le contrôle sur notre périphérique connecté au réseau.

IPSec : architecture de sécurité IP du réseau

Tout d'abord, analysons l'architecture de sécurité utilisée par les deux protocoles. L'architecture de sécurité IP (IPSec, Internet Protocol Security Architecture, RFC 4301) est conçue pour donner une sécurité de haute qualitépour IPv4 et IPv6. En fait, l'architecture IPSec a été conçue justement pour IPv6 (RFC 1883). IPSec inclut l'intégrité, l'authentification et une certaine confidentialité au niveau des datagrammes. L'architecture se compose de quelques protocoles servant à envoyer les données authentifiées ou chiffrées à travers les réseaux IP (cf. la Figure 1).

IPSec est placé dans la couche réseau – elle est donc une architecture transparente par rapport aux protocoles applicatifs qui possèdent leurs propres mécanismes de sécurité, comme par exemple SSL ou PGP. Pourtant, ce n'est pas un seul protocole, mais un jeu de protocoles offrant les services de sécurité. Ils se composent de protocoles de sécurité : Authentication Header (AH) et Encapsulating Security Payload (ESP) et les mécanismes pour la gestion des clés de cryptage : IP Security Association and Key Management Protocol (ISAKMP), RFC 4306 et Internet Key Exchange (IKE). IPSec définit ce qu'on appelle concept d'association de sécurité (SA, Security Association) qui détermine la politique de sécurité entre deux parties de la connexion appliquée au datagramme en fonction de son expéditeur, son destinataire et de son contenu. Une AS est identifiée de façon unique par trois variables : l'index du paramètre de sécurité (SPI, Security Parameter Index), l'adresse IP destination, et l'identifiant du protocole de sécurité (51 pour AH et 50 pour ESP). SPI est une valeur de 32 bits utilisée pour choisir parmi les différentes SA ayant la même destination et utilisant le même protocole IPsec. SA ne contient pas d'identification de l'adresse IP source car – pour assurer une communication bilatéralement sûre – encore une association de sécurité doit être créée (pour la direction inverse). IPSec admet qu'AS existe déjà et ne protège que la création appropriée des datagrammes.

Chaque noeud IPSec maintient deux bases de données : la base de données de la politique de sécurité (SPD, Security Policy Database) et la base de données des associations de sécurité (Security Policy Associations). Le jeu de paramètres pour chaque AS (SPI, protocole de sécurité, mode, algorithme de cryptage, clé et autres) est stocké dans la base de données SPA. La base de données SPD contient le sommaire des préférences de sécurité suivant l'ordre de leur utilisation dans le datagramme IP. Chaque entrée dans cette base se compose d'un sélecteur et une actions (utiliser IPSec, détruire le datagramme ou ne pas utiliser IPSec). Si un datagramme contient des valeurs correspondant au sélecteur enregistré, l'action qui y est associé est utilisée.

Quand le système envoie un paquet nécessitant une protection particulière, il recherche dans la base de données une association de sécurité, exécute les opérations appropriées et met SPI de l'association de sécurité dans l'en-tête du datagramme. Le récepteur, à partir de la commande du datagramme, retrouve l'AS dans la base de données suivant l'adresse destination/SPI et réalise les opérations appropriées.

La gestion des associations de sécurité se fait à travers le protocole ISAKMP. Pourtant, ISAKMP ne définit pas son propre mécanisme d'échange des clés secrètes entre les récepteurs et les stations envoyant les paquets avec ESP ou AH, c'est pourquoi, en cas d'une échange automatique des clés (l'échange manuelle est compliquée), il faut utiliser Internet Key Exchange, ce qui est une composante du contenu concret de l'association de sécurité. On utilise ici les algorithmes d'échange des clés de type Diffie-Hellman en admettant que les deux parties de la communication sont connues. Cette échange est assurée à l'avance par les mots de passe et les certificats numériques communs.

Pour la gestion des clés dans IPSec, une infrastructure d'authentification homogène PKI est nécessaire. Le développement IKE était très complexe et la spécification de la meilleure version du protocole IKEv2 (RFC 4306) a été publiée à la fin de dernière année. Néanmoins, son implémentation est pour l'instant assez rare, bien que sans le protocole spéciale permettant la distribution des clés il soit impossible d'utiliser IPSec...

Protocoles AH et ESP

L'authentification et l'intégrité des messages IP sont assurées par un complément au datagramme IP sous forme d'un en-tête d'authentification (Authentication Header, RFC 4302) saisi à la place de l'en-tête IP orginal qui utilise le chiffrement à l'aide de la clé publique. Le chiffrement concerne toutes les partie du datagramme qui ne change pas. On utilise ici l'algorithme de chiffrement MD5. Le chiffrement se fait à la source avant la fragmentation du datagramme, et le déchiffrement est effectué après la réception par la station destination.

L'authentification AH se fait à l'aide de ce qu'on appelle code d'authentification de message (MAC, Message Authentication Code). Si l'on utilise le hachage à sens unique, on obtient HMAC (Hash-Based MAC) ; il est en fait le résultat de la combinaison d'une fonction hachage avec une clé secrète. Il est possible de hacher un texte quelconque en obtenant en résultat un condensé d'une taille déterminée. À la différence d'une signature numérique, pendant le cryptage du condensé, on se sert d'une clé privée de la même longueur. HMAC utilise l'algorithme MD5 (RFC 2085 et 2403) ou SHA-1 (RFC 4305), un algorithme plus fort et plus puissant. L'AH est une bonne méthode là où l'authentification de chaque datagramme à part est suffisant. L'AH possède un identifiant du protocole de sécurité, le numéro de séquence et la somme de contrôle (cf. la Figure 2).

Le second protocole d'IPSec, Encapsulating Security Payload (ESP, RFC 4303), assure la confidentialité des données en cryptant le contenu et l'en-tête du paquet. Il offre aussi les services d'authentification similaires à AH (la comparaison de l'AH et de l'ESP est présentée dans le Tableau 1). L'ESP convient mieux dans les cas plus sérieux, quand il est nécessaire d'authentifier et de chiffrer le contenu des datagrammes pour les protéger contre l'écoute ou les abus. L'ESP permet le chiffrement avec l'authentification (null encryption, RFC 2410). L'ESP définie le contenu possible du datagramme IP. Il se compose d'un en-tête qui comprend les informations concernant la politique de sécurité (SPI), du numéro de séquence, et éventuellement spécifie l'algorithme de chiffrement (par exemple DES), cf. la Figure 3. Les données sont chiffrées d'une façon appropriée, et à la fin, il y a la somme de contrôle qui permet de confirmer la validité du datagramme.

<<TABELA posx=8;0r posy=b fit=W:166 grow=H>>

Tableau 1. Comparaison des protocoles AH et ESP

	AH	ESP
authentification de la source du message	oui	au choix
intégrité des données transférées	tak (y compris l'en-tête)	oui (excepté l'en-tête)
protection contre le rejeu	au choix	oui
utajnienie przenoszonych danych (szyfrowanie)	non	oui

<</TABELA>>

L'AH et l'ESP utilisent le hachage pour vérifier si lors de la communication, un changement du paquet n'a pas eu lieu. Vu que pendant la transmission, l'en-tête changé, les deux protocoles ajoutent la valeur du contrôle d'intégrité (ICV, Integrity Check Value) aux certains en-têtes appartenant aux couches supérieures.

Modes tunnel et transport

L'association de sécurité fonctionne en deux modes : transport et tunnel (Figure 4). En mode transport, l'en-tête de sécurité est mis entre l'en-tête origine du datagramme IP et les données, tandis qu'en mode tunnel, un nouvel en-tête est créé pour le datagramme, après lequel vient encore l'en-tête de sécurité.

L'ESP en mode transport chiffre et authentifie les données transmises, mais n'authentifie pas de l'en-tête du datagramme. L'AH en mode transport authentifie authentifie les données transmises et les champs sélectionnés de l'en-tête du datagramme. En mode transport, le protocole ESP est identifié dans l'en-tête IP à l'aide de l'ID de protocole IP 50 et le protocole AH - 51. Les deux en-têtes contiennent aussi le champ identifiant le type de données que comprend la charge utile, comme TCP ou UDP. Le mode transport convient pour les communications de bout en bout effectuées via un réseau externe (cf. la Figure 5).

Quant au mode tunnel, le datagramme entier (intérieur) est encapsulé dans un autre datagramme avec (c'est-à-dire, il sera chiffré avant l'encapsulation) un en-tête non chiffré (datagramme extérieur) qui servira de tracer la route dans le réseau. Les adresses IP de l'en-tête IP extérieur représentent les points d'arrêt du tunnel, alors que celles de l'en-tête IP encapsulé constituent les véritables adresses source et de destination. Ce mode est utile pour protéger le trafic entre les différents réseau et fonctionne entre les routeurs et les systèmes terminaux. Les routeurs reçoivent uniquement les en-têtes des datagrammes extérieures. Le mode tunnel est utilisé par défaut pour la construction de VPN (Virtual Private Network; cf. la Figure 6).

L'utilisation de l'ESP en mode transport et en mode tunnel – en fonction des parties du datagrammes authentifiées et chiffrées – est présentée sur la Figure 7.

Les mécanismes ESP et AH peuvent être exploités entre deux noeuds du réseau (entre les utilisateurs finals ou entre les routeurs), en transmission multicast et unicast. Les mécanismes de protection peuvent s'ajouter, ce qui veut dire qu'un datagramme peut contenir les deux en-têtes : AH et ESP. AH assure l'intégrité des données en mode sans connexion et l'authentification de la source IP des paquets, mais n'offre pas la confidentialité des données au moyen du chiffrement. L'ESP permet le chiffrement, mais ne protège pas de nouveaux en-têtes IP du paquet origine encapsulé. Pour avoir une authentification puissante avec la confidentialité des informations transmises, il faut utiliser la combinaison de l'AH avec l'ESP en deux modes : aussi bien en mode transport que tunnel.

Translation des adresses : NAT

La translation des adresses (NAT, Network Address Translation; RFC 3022) est souvent utilisée dans la pratique. Dans Ipv4, il y en a deux causes principales : limiter le nombre d'adresses IP uniques nécessaires pour les réseaux privés et améliorer la sécurité de la communication entre les réseaux privés et Internet. La NAT a été mis au point pour répondre au manque d'adresses IP dans le protocole dû au fait que l'espace adressable n'est pas utilisé de manière optimale - une adresse est définie seulement sur 32 bits. Cette situation provisoire durera jusqu'au moment du passage à la nouvelle sixième version du protocole IP, permettant l'adressage unique du plus grand nombre de noeuds du réseau. Maintenant ces adresses ont la longueur de 128 bits.

La fonction NAT est bien connue, alors la rappellerons en quelques mots. Tout d'abord, il ne faut pas oublier que le réseau des connexions à Internet via la NAT doit embrasser au moins une adresse IP importante qui est affectée à un routeur ou à une machine connectée à Internet. Une application spéciale NAT (appelée NAT box) traduit les adresses dans les datagrammes entrants et sortants de façon à remplacer l'adresse source dans les datagrammes sortants par son adresse globale et l'adresse destination dans les datagrammes entrants par l'adresse privée de la station cible donnée (d'après RFC 1918). Du point de vue d'un utilisateur externe, tous les datagrammes arrivent à la NAT et en réponse, sortent à partir de celui-ci. Du point de vue d'un utilisateur interne, la NAT est un routeur connecté à Internet.

Désavantages de la NAT

Dans plusieurs applications, les règles de la NAT sont inacceptables car celles-ci ne peuvent pas fonctionner correctement avec la translation des adresses. La NAT ne peut pas coopérer avec les protocoles qui utilisent les informations sur les adresses à l'intérieur d'un simple datagramme. L'en-tête contient les adresses traduites à l'aide de la NAT, mais à l'intérieur des datagrammes, la NAT n'effectue pas l'opération de translation d'adresses. La nouvelle version de la NAT est capable de résoudre ce problème. En générale, la NAT n'est pas adoptée aux différentes tâches d'IP, il ne faut donc pas s'attendre à ce que les applications fonctionnent aussi efficacement en présence de la NAT comme elles étaient conçues. Il serait peut-être juste que toutes les applications supportent la NAT, mais à vrai dire, cette solution n'est pas bonne vu la performance, l'extensibilité et l'implémentation des applications.

La NAT pose des problèmes même sous IPSec où la communication se fait entre deux extrémités. Cette situation ne peut pas être comparée au fait quand une adresse de substitution. IPSec, qui utilise l'en-tête authentifié, calcule la valeur d'authentification à partir du datagramme entier – y compris son adresse IP source et destination. Une modification quelconque de l'adresse IP, par exemple au moyen de la translation, entraîne le calcul d'une autre valeur, et de cela, l'authentification est refusée. La NAT doit être donc utilisée avant le traitement avec IPSec. En cas d'ESP, l'authentification ne se fait pas à partir d'un en-tête extérieur, alors la translation NAT peut avoir lieu après l'application d'IPSec.

Si l'on combine la translation d'adresses et de ports (NAPT, Network Address and Port Translation), on utilise une adresse IP et plusieurs ports TCP et UDP (l'objectif : économiser les adresses IP). La NAT établit les valeurs des ports juste après l'en-tête IP dans l'unité de données. Avec l'IPSec, le principe précédent ne peut pas être satisfait. De plus, l'ESP chiffre l'en-tête TCP ou UDP encore en mode tunnel, ce qui est inadmissible pour la NAT ; pour cette raison, la translation des adresses doit avoir lieu avant l'application d'IPSec. Plusieurs nouveaux produits IPSec supportent l'utilisation de la NAT en implémentant l'encapsulation UDP, mais ce n'est pas une solution universelle.

Protocole de nouvelle génération IP version 6 et sa protection

La nouvelle version du protocole IP (IPng, IP next generation), portant le numéro 6 (IPv6; RFC 2460) a été élaborée il y a dix ans. La nécessité d'apporter les améliorations à IPv4 était lié au système d'adressage insuffisant et à son utilisation inefficace allouant les blocs d'adresses trop grands. IPv6 résout tous ces problèmes grâce au format permettant d'utiliser 10³⁸ d'adresses uniques, mais sa mise en point dans les réseaux modernes est motivée aussi par d'autres facteurs que seulement l'espace d'adressage plus large.

Grâce à l'adressage individuel, IPv6 permet une communication sans intermédiaires entre les stations basée sur la règle peer-to-peer. Il supporte mieux que son prédécesseur de nouvelles applications et services tels que VoIP, les jeux en ligne menés par plusieurs utilisateurs, les vidéoconférences, les services de transfert des données avec la téléphonie mobile, ainsi que la connexion à distance des senseurs (par exemple RFID, Radio Frequency IDentification), les ménages informatisés, les bâtiments intelligents ou grid computing.

Mais il ne s'agit pas d'une tout à fait nouvelle architecture réseau car IPv6 a hérité beaucoup de caractéristiques d'IPv4. Il y a le même service datagramme, les mêmes protocoles de transport et pratiquement les mêmes applications. Pourtant, IPv6 offre aussi de nouveaux éléments, tels que l'espace d'adressage plus étendu, l'autoconfiguration, le support des technologies mobiles et la politique de sécurité intégrée.

Avantages d'IPv6 par rapport à IPv4

l'espace d'adressage plus étendu,
la simplification du format de l'en-tête du datagramme,
le support obligatoire pour IPSec,
le support élargi pour les protocoles IP mobiles.

Adressage dans le protocole IP version 6

Pour satisfaire aux exigences liées à l'élargissement de l'espace d'adressage pour IP, IPv6 utilise 128 bits au lieu de 32 (RFC 4291). L'espace d'adressage devient alors quasi infini : 2¹²⁸. L'adresse IPv6 type est divisée en deux parties : le préfixe et l'identificateur d'interface. Un identificateur d'interface peut avoir plusieurs adresses IPv6. Il existe différents types d'adresses Ipv6 : adresses mono-utilisateur (unicast; RFC 3587), multidestinataires (multicast; RFC 3306, 3307 et 3956) et les adresses correspondant à un groupe d'interfaces (anycast) – seuls les deux premiers types sont utilisés dans IPv4. Le nouveau type d'adresse anycast est fort utile dans plusieurs applications modernes qui utilisent les serveurs diffusés dans le réseau. D'autre part, les adresses réservées peuvent être pour un intrus le but de l'attaque intéressant – de cela, les adresses anycast disponibles globalement devraient être définies uniquement pour les routeurs. Pour une adresse anycast destination, il n'existe pas aucun mécanisme d'autorisation ce qui rend plus faciles les attaques de type spoofing et masquerade.

Les adresses ont deux fonctions de base, coexistantes dans IPv4, mais séparées dans Ipv6 – la fonction de localisation et la fonction d'identification. Les informations sur la localisation sont nécessaires au routeur parce qu'elles déterminent la façon de trouver le chemin au but. Elles offrent au moins trois niveaux d'agrégation : (TLA, Top-Level Aggregator; NLA, Next-Level Aggregator oraz SLA, Site-Level Aggregator, RFC 3587).

L'identification (identificateur) signifie un périphérique spécifique ou son interface. L'agrégation et l'allocation hiérarchique des adresses sont utilisées effectivement pour router globalement les données, vu que les décisions concernant le trajet du paquet dans le réseau sont prises à partir des bits initiaux de l'adresse suivant les préfixes de plus en plus longs et spécifiques.

Dans Ipv6, les premiers 64 bits déterminent en général l'information sur la localisation pour qu'il soit possible d'atteindre un certain intervalle (site). Les 64 bits suivants signifient l'identification du périphérique dans le domaine défini. Le passage à un nouveau FAI nécessite le changement du locateur, mais pas de l'identificateur. Les adresses hiérarchiques IPv6 plus longues satisfont avant tout les exigences concernant la recherche effective du chemin de paquet dans le réseau car elles permettent une agrégation plus facile des adresses suivant les niveaux hiérarchiques du réseau, le FAI (connexion), l'entreprise utilisant Internet et autres (RFC 3587).

La notation des adresses IPv6 diffère de celle d'IPv4. Les adresses sont écrites en notation hexadécimale où les 8 groupes de 16 bits sont séparés par un signe deux-points. L'adresse peut se présenter par exemple ainsi : FBCD:1234:5678:9001:2222:AB12:2345:6789. Il est permis de supprimer de la notation les chiffres zéro non significatifs, mais une seule fois dans une notation donnée, autrement cela pourrait porter à confusion. Par exemple, l'adresse FEDC: 0000:0000:0000:0000:0000:0000:0110 peut notée comme FEDC::110. IANA(Internet Assigned Numbers Authority) a affecté à RIPE NCC (Réseaux IP Européens Network Coordination Centre) la plage d'adresses (hex2001:600::/23). Quand nous récapitulons tous les types d'adressages IPv6, nous obtiendrons une liste assez longue. L'IPv6 permet d'affecter à une interface réseau plusieurs adresses individuelles qui peuvent être globalement uniques (global), seulement locales (site-local) ou celles dont la validité est restreinte à un lien (link-local). Dans le cadre d'IPv6, les adresses peuvent être divisées suivant l'état de la configuration (RFC 2462) en préférées (preferred) et déconseillées (deprecated) ; éventuellement, conformément à RFC 304, en publiques (public addresses) et temporaires (temporary addresses).

La connexion aux plusieurs FAI, c'est-à-dire multihoming, permet d'affecter plusieurs adresses à un noeud – aussi pour les interfaces virtuelles ou l'interface tunnel. De cela, pendant l'établissement d'un connexion, les implémentations d'IPv6, dans les noeuds extrêmes et les routeurs, doivent souvent choisir parmi plusieurs adresses sources et destination. Ces situations sont résolues par l'intermédiaire du mécanisme de choix d'adresses (RFC 3484), commun à toutes les implémentations, mais qui n'est pas prioritaire par rapport au choix des adresses définies par chaque application. En cas d'implémentations doubles (IPv4 avec IPv6), il faut décider quel type d'adresses doit être utilisé.

Configuration automatique

IPv4 n'offre pas directement une configuration automatique de la machine lors de sa connexion au réseau. L'alternative pour la configuration manuelle de chaque machine est le protocole DHCP. À partir de la requête de la machine, le serveur DHCP lui affectera une adresse IP et fournira les informations nécessaires pour le travail dans le réseau donné. Dans IPv6, il est possible d'utiliser le protocole DHCPv6 remanié, mais l'apport positif d'IPv6 est la configuration automatique (RFC 2462 et RFC 3041) qui n'exige pas aucun serveur.

L'autoconfiguration n'a pas été intégrée dans le projet IPv6 pas à cause du manque de confiance envers les utilisateurs finals, mais pour faciliter les modifications d'ISP, supporter les technologies mobiles, assurer l'unicité des adresses et supporter IP sur les équipements qui ne sont pas surveillés pas aucun administrateur réseau (il s'agit par exemple des dispositifs récepteurs domestiques). L'auto configuration sans état permet aussi aux noeuds une communication dans les réseaux sans routeurs (réseaux ad hoc).

L'autoconfiguration utilise le protocole ICMPv6 (Internet Control Message Protocol) et est basée sur la découverte des voisins (NDP, Neighbor Discovery Protocol, RFC 2461 et RFC 3122). L'équipement connecté au réseau IPv6, en premier lieu crée son adresse locale (link-local) à partir du préfixe prédéfini hexFE80, et ensuite, ajoute à celui-ci son identificateur (EUI, End User Identifier). L'équipement vérifie dans le réseau si cette adresse n'est pas utilisée par quelqu'un d'autre. Tous les noeuds dans un segment répondront à une station donnée, et après l'échange des informations pourront communiquer sans l'intermédiaire des serveurs ou routeurs.

Les équipements suivent les messages des routeurs qui envoient régulièrement l'information (router advertisement) annonçant aux équipements l'adresse du préfixe (prefix adress) d'un réseau donné et l'information sur la passerelle (default gateway) et sa durée de vie. En même temps, grâce à ces informations, l'équipement saura s'il faut utiliser la configuration avec état ou sans état. L'équipement nouvellement connecté peut demander tout seul ces informations à partir des routeurs, alors il ne doit pas attendre leur annoncement périodique. Dans le cadre de la configuration sans état, à partir du préfixe annoncé, l'équipement construira sa propre adresse IPv6 unique en ajoutant à ce préfixe l'EUI de l'adresse locale. Si l'équipement effectue la configuration avec état, DHCPv6 est utilisé.

Pour des raison de sécurité, il faut vérifier si l'information diffusée dans le réseau provient d'un routeur autorisé et quelles exigences de sécurité concernent la découverte des voisins que nous avons déjà mentionné.

SEND (SEcure Neighbor Discovery; RFC 3971) définit de nouvelles possibilités d'ICMPv6 dans le cadre du protocole NDP, sur la base des signatures utilisant les clés publiques. La fonction de hachage de la clé publique est utilisée pour la génération de l'adresse, les routeurs sont certifiés par l'intermédiaire de X.509, les données sont signées et les marqueurs de temps confirment le moment de la création du message.

Datagramme IP version 6

IPv6 transmet efficacement aux extensions des en-têtes optionnels les informations qui ne sont pas nécessaires dans le datagramme. L'en-tête obligatoire (cf. la Figure 9) a la longueur constante (40 octets) et ne contient que 8 champs (la Figure 8 présente le format du datagramme IPv4). Après l'en-tête obligatoire peuvent venir les en-têtes optionnels d'une longueur variable. Les données qu'ils contiennent seront utilisées dans les noeuds extrêmes, mais très rarement dans les routeurs. Ainsi, les routeurs ne s'occupent que de l'en-tête d'une longueur constante, moins compliqué que dans IPv4, ce qui a permis d'accélérer son fonctionnement.

Format de l'en-tête obligatoire

version (version) – numéro de la version du protocole (6),
priorité (priority) – permet à la source d'identifier le priorité de chaque datagramme par rapport au reste des datagrammes provenant d'une même source ; il s'agit du priorité du point de vue de la transmission et de la livraison,
étiquette de flux (flow label; RFC 3697) – permet d'identifier les datagrammes spécialement traités lors du routage ; les équipements et les routeurs qui ne supportent pas ce champ, ne peuvent pas le changer. Le flot de données est défini comme une suite des datagrammes envoyés d'une source à un destinataire ou à un groupe de destinataires. Le marquage du flux et le champ précédent priority permettent ensemble de définir la priorité de la transmission dans le cadre de QoS (Quality of Service) – le contrôle de la bande passante. Vu qu'il n'existe pas de mécanisme d'authentification, les attaques DoS (Denial of Service) ou les vols du service peuvent avoir lieu. C'est pourquoi, les mécanismes de type pare-feu ne doivent pas baser entièrement sur les marquages du flux pour prendre les décisions,
longueur des données dans le datagramme (payload length) – la longueur de la partie restante du datagramme Ipv6, c'est-à-dire la longueur de tous les en-têtes complémentaires et la longueur du champ de données,
en-tête suivant (next header) – identifie le type de l'en-tête directement après l'en-tête obligatoire du datagramme IPv6,
nombre maximal de routeurs (hop limit) – le nombre de routeurs permis (une analogie au champ de durée de vie sous IPv4 – TTL, Time To Live) ; chaque routeur le réduit d'une unité. Si cette valeur est réduite à 0, le datagramme ne peut pas être transmis plus loin et un message ICMP soit être généré,
adresse source (source address) – l'adresse de la source d'une longueur de 128 bits,
adresse destination (destination address) – l'adresse du destinataire voulu d'une longueur de 128 bits (dans certains cas, il ne s'agit pas d'un périphérique cible, à moins qu'un qu'une extension de l'en-tête pour diriger n'a été utilisée).

À la différence d'IPv4, l'en-tête obligatoire ne contient pas ici une information superflue sur la longueur de l'en-tête, et en même temps, il ne contient pas non plus la somme de contrôle en se référant aux autres couches. Dans IPv6, contrairement à IPv4, la fragmentation d'après la longueur admissible de l'unité de données (MTU, Maximum Transmission Unit) n’est réalisée que par les noeuds sources et les routeurs sur le trajet ne le peuvent pas. Cela veut dire que la MTU minimale d'un transfert donné doit être déduite par l'ordinateur source (RFC 1981) avant l'envoi du datagramme. Le fait de défendre la fragmentation des datagrammes aux routeurs réduit dans une certaine mesure les abus de la fragmentation qui ont pour but de violer la sécurité de la transmission.

Après l'en-tête obligatoire IPv6, peuvent venir certains en-têtes d'extension optionnels. Chaque en-tête identifie l'en-tête suivant – il contient le champ définissant le type de l'en-tête consécutif (l'exemple sur la Figure 10). Si il n'y pas aucun en-tête suivant, le protocole de transport est spécifié par l'intermédiaire du numéro du protocole, qui est le plus souvent identique à celui dans IPv4 (6 pour TCP, 17 pour UDP ou 46 pour RSVP, mais 58 pour ICMPv6). La valeur 59 dans le champ En-tête suivant indique que rien ne suit cet en-tête – s'il y en a quand même des données, elles seront négligées.

Ordre des en-têtes optionnels

Une revue des en-têtes et leurs identificateurs sont présentés dans le Tableau 2 :

en-tête des options sauts après sauts (hop-by-hop options header) – définit les options qui doivent être examinées et traitées par chaque routeur le long du chemin emprunté par le datagramme, par exemple l'avertissement du routeur sur le contenu du datagramme intéressant (RFC 2711, le choix de l'identificateur 5) ou le support de l'emploi de ce qu'on appelle jumbogrammes (RFC 2675, le choix de l'identificateur 194), les datagrammes d'une taille supérieure à 65 Ko et inférieure à 4 Mo,
en-tête des options de destination (destination options header) – contient les informations optionnelles pour la destination (l'en-tête optionnel peut être placé après tous les autres en-têtes et il définit l'action du dernier noeud destination).
en-tête de routage (routing header) – donne une liste des routeurs qui doivent être visités le long du trajet vers la destination ; la destination doit ensuite utiliser cet en-tête pour déterminer le trajet dans le sens inverse,
en-tête de fragmentation (fragment header) – contient les informations servant à fragmenter et rassembler les datagrammes. La fragmentation n'est réalisé que par un noeud source, c'est pourquoi le noeud source doit être capable à déterminer la MTU pour que le datagramme ne soit pas détruit lors de la transmission. Le rassemblage du datagramme est effectué par la station destination,
en-tête d'authentification (AH) – assure l'intégrité et la véridicité du datagramme,
en-tête d'encapsulation de charge utile sécurisée (ESP) – assure la protection des données transférées dans le datagramme, leur authenticité et intégrité ; si le chiffrement est nul (null), seuls les services d'authentification et d'intégrité sont assurés.

Tableau 2. Les en-têtes d'extension et leurs identificateurs

identificateur	en-tête d'extension
0	hop-by-hop
43	routing
44	fragment
50	encapsulating security payload header, ESP
51	authentication header, AH
59	no next header
60	destination options
62	mobility

IPv6 utilise obligatoirement le protocole de sécurité IPSec, ce qui signifie qu'il supporte nativement l'authentification, le chiffrement, VPN. Avec le nouveau protocole, de nouveaux types d'attaques apparaissent, il ne faut donc pas attendre qu'IPv6 sera supersécurisé. En particulier, il faut se rendre compte du fait qu'IPSec veille à la sécurité de la couche réseau et pas des applications spécifiques, alors ne préviendra les attaques contre celles-ci. IPv6 ne protégera pas non plus contre les attaques par inondation de datagrammes.

Les mécanismes d'authentification et de chiffrement sont ajoutés au datagramme IPv6 au moyen des en-têtes d'extension optionnels. Même si le support de ces en-têtes est obligatoire, IPv6 ne les détermine pas à l'aide des applications, c'est pourquoi la présence de la protection au niveau de transport ne dépend que de l'utilisateur et des applications. On ne peut pas donc prétendre qu'IPv6 est un protocole plus sécurisé que son prédécesseur, mais on peut dire qu'IPv6 est un pas en avant pour l'élargissement de l'authentification et de la protection au niveau des protocoles de transmission. L'AH assure l'intégrité des données (MAC) et l'authentification (vérification de l'identité de la source), mais ne garantit pas la confidentialité. Le calcul de MAC est réalisé par la source avant la fragmentation du datagramme, et le contrôle de l'intégrité se fait après le rassemblage du datagramme dans le noeud destination. Le MAC concerne toutes les parties du datagramme qui ne changent pas pendant le trajet dans le réseau (comme pour quelques types d'en-têtes). Pour le MAC, on utilise MD5 et SHA-1.

L'ESP a pour but de chiffrer les données. On peut chiffrer soit les données de niveau transport, c'est-à-dire le segment TCP/UDP ou le message ICMP (transport-mode), soit le datagramme IPv6 entier (tunnel-mode ;cf. la Figure 11). Dans le premier cas, le chiffrement est réalisé par le noeud source, et lors du trajet, les routeurs ne s'intéressent qu'aux en-têtes obligatoires non chiffrés du datagramme IPv6 et aux en-têtes d'extension non chiffrés. Quant au mode tunnel, tout le datagramme est chiffré (intérieur) et il est encapsulé dans un autre datagramme avec l'en-tête non chiffré (datagramme extérieur). Cette méthode ne fonctionne qu'entre les routeurs collaborants et pas entre les noeuds extrêmes. Les routeurs identifient les datagrammes uniquement suivant l'en-tête extérieur.

Les mécanismes de protection peuvent être combinés, ce qui veut dire qu'un datagramme IPv6 peut contenir les deux en-têtes : AH et ESP (cf. la Figure 12). Vu que le chiffrement est réalisé avant l'authentification, le datagramme entier est authentifié avec les parties chiffrées et non chiffrées ; vu que c'est l'authentification qui est effectuée en premier lieu, l'en-tête est insérée dans le datagramme intérieur qui est ensuite chiffré en son entier. Cette solution n'est pas trop heureuse car on ne profite pas de l'authentification.

Le protocole IPv6 n'assure pas la protection contre la non-repudiation, le rejeu (replay) et notamment contre les attaques de type denial-of-service (DoS).

Le mécanisme NAT élargi dans les protocoles IPv4 n'est