Difference between revisions of "MOOC:Compagnon Act25-s6"
From Livre IPv6
m (Bstevant moved page MOOC:Compagnon Act25 to MOOC:Compagnon Act25-s6) |
|||
| (21 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
__NOTOC__ | __NOTOC__ | ||
| − | =Activité | + | =Activité 25 : Le mécanisme d’extension de l'en-tête IPv6= |
| + | <!-- | ||
| + | Principe d'extension : Adapter le niveau IP à de nouvelles fonctionnalités | ||
| + | * Exemple de fonctionnalités | ||
| + | ** Extension de routage / Mobilité | ||
| + | ** La sécurité | ||
| + | |||
| + | * Next Header | ||
| + | * Quelques exemples de fonctionnalités | ||
| + | ** Extension de routage / Mobilité | ||
| + | ** Extension de fragmenntation | ||
| + | ** Extension d'authentification | ||
| + | * Ressources supplémentaires | ||
| + | --> | ||
| + | {{Approfondissement}} | ||
== Introduction == | == Introduction == | ||
| − | Les extensions de l'en-tête IPv6 visent à ajouter des fonctionnalités supplémentaires à l'acheminement d'un paquet dans l'Internet. Ces extensions vont impliquer le traitement de ces fonctionnalités au niveau réseau | + | Les extensions de l'en-tête IPv6 visent à ajouter des fonctionnalités supplémentaires à l'acheminement d'un paquet dans l'Internet. Ces extensions vont impliquer le traitement de ces fonctionnalités au niveau réseau, soit par le destinataire du paquet IPv6, soit par les routeurs intermédiaires en charge de l’acheminement du paquet IPv6. |
| − | + | ||
| − | + | ||
| − | De nombreuses extensions ont été définies, afin d'assurer des fonctions comme | + | De nombreuses extensions ont été définies, afin d'assurer des fonctions comme le routage par la source, la gestion de la fragmentation, la confidentialité des communications (mécanisme ''ipsec''), etc. |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
Le mécanisme d'extension de l'en-tête IPv6 est assez souple pour pouvoir inclure d'autres fonctionnalités futures. Dans cette activité, nous allons nous intéresser au principe du traitement des extensions au moyen d'exemples simples et démonstratifs de ce mécanisme. | Le mécanisme d'extension de l'en-tête IPv6 est assez souple pour pouvoir inclure d'autres fonctionnalités futures. Dans cette activité, nous allons nous intéresser au principe du traitement des extensions au moyen d'exemples simples et démonstratifs de ce mécanisme. | ||
| Line 19: | Line 27: | ||
Les extensions peuvent être vues comme un protocole 3.5, entre les couches 3 (réseau) et 4 (transport) du modèle OSI. En effet, à part l'extension de proche-en-proche, qui est traitée par tous les routeurs traversés, les autres extensions ne sont traitées que par le destinataire du paquet (i.e. celui spécifié dans le champ adresse de destination du paquet IPv6). | Les extensions peuvent être vues comme un protocole 3.5, entre les couches 3 (réseau) et 4 (transport) du modèle OSI. En effet, à part l'extension de proche-en-proche, qui est traitée par tous les routeurs traversés, les autres extensions ne sont traitées que par le destinataire du paquet (i.e. celui spécifié dans le champ adresse de destination du paquet IPv6). | ||
| − | Une extension a une longueur multiple de 8 octets (64 bits). Elle commence | + | Une extension a une longueur multiple de 8 octets (64 bits). Elle commence par un champ <tt>Next header</tt> qui définit, sur un octet, le type d'extension ou de protocole qui suit. Pour les extensions de longueur variable, l'octet suivant contient la longueur de l'extension en mots de 8 octets, le premier mot n'étant pas compté. Par exemple, une extension de 16 octets aura une longueur de 1. |
| − | Si d'un point de vue théorique les extensions sont supérieures aux options d'IPv4, dans la réalité très peu sont utilisées à grande échelle et restent du domaine de la recherche. | + | Si, d'un point de vue théorique, les extensions sont supérieures aux options d'IPv4, dans la réalité très peu sont utilisées à grande échelle et restent du domaine de la recherche. |
| − | '''''Nota :''''' '' | + | '''''Nota :''''' ''dans la pratique, l'extension la plus couramment rencontrée est probablement l'option de fragmentation à la source. En effet, certains protocoles applicatifs sur UDP, tel que NFS, supposant que la fragmentation existe au niveau réseau, produisent des messages de taille quelconque sans se soucier du MTU. Comme il n'est pas envisageable de modifier ces applications largement déployées, la couche réseau IPv6 doit être capable de gérer la fragmentation. IPv6 impose simplement que cette dernière se fasse à la source.'' |
| − | Une présentation illustrée des | + | Une présentation illustrée des extensions IPv6 peut être consultée sur le site de Cisco<ref>Cisco (2006) White paper.[http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html IPv6 Extension Headers Review and Considerations]</ref>. |
== Le champ ''Next Header'' == | == Le champ ''Next Header'' == | ||
| Line 37: | Line 45: | ||
== Intégration des extensions d’en-tête dans le paquet IPv6== | == Intégration des extensions d’en-tête dans le paquet IPv6== | ||
| − | Quand il y a plusieurs extensions dans un même datagramme, les extensions sont placées selon un ordre qui dépend de leur portée: | + | Quand il y a plusieurs extensions dans un même datagramme, les extensions sont placées selon un ordre qui dépend de leur portée : |
* extensions impliquant tous les routeurs intermédiaires : ''Hop-by-Hop'' ; | * extensions impliquant tous les routeurs intermédiaires : ''Hop-by-Hop'' ; | ||
* extensions impliquant seulement certains routeurs désignés : ''Routing'' ; | * extensions impliquant seulement certains routeurs désignés : ''Routing'' ; | ||
| Line 55: | Line 63: | ||
=== Fragmentation === | === Fragmentation === | ||
| − | |||
| − | + | Nous avons vu la fragmentation en détail lors de l'activité consacrée à la taille des paquets IPv6. Les points essentiels à rappeler sont que la fragmentation en IPv6 est une fonction d'hôtes exclusivement, et que par souci d'efficacité, l'adaptation de la taille de l'unité de données applicatives en unité de transfert est du ressort de la couche de transport. Cependant, lorsque ce n'est pas possible, en dernier ressort, la fragmentation est faite par IPv6. Les informations pour la fragmentation sont placées dans une extension d'en-tête IPv6 identifiée par la valeur 44. | |
| + | D'un point de vue du codage, l'en-tête et les extensions qui concernent les routeurs intermédiaires (pour l'instant "proche en proche" et "routage par la source") sont recopiées dans chaque fragment, tandis que les autres extensions et l'en-tête de niveau 4 ne seront présents que dans le premier fragment. | ||
| − | + | La fragmentation en IPv4 n'est pas très performante. Quand un routeur ne peut pas transmettre un paquet à cause de sa trop grande taille, il doit le transmettre en fragments. Comme l'Internet n'est pas fiable, un fragment peut se perdre. Le destinataire ne peut rassembler les fragments. Cela revient à perdre tous les fragments. Il est donc plus efficace de faire les fragments avant la couche IP. Ainsi le fragment devient un paquet IP à la bonne taille. Maintenant, en cas de perte, seul le paquet perdu sera retransmis, évitant ainsi la retransmission de gros blocs de données. | |
| − | + | Il est plus intéressant d'adapter la taille des paquets à l'émission. Ceci est fait en utilisant les techniques de découverte du MTU (voir RFC 8201 : Mécanisme de découverte du PMTU). En pratique, une taille de paquets de MTU 1280 octets est une bonne garantie d'acheminement du paquet. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
=== Extensions d'authentification (AH) et de confidentialité (ESP) === | === Extensions d'authentification (AH) et de confidentialité (ESP) === | ||
| Line 80: | Line 75: | ||
L'extension d'authentification (AH : Authentication Header) décrite dans le RFC 4302 permet de s'assurer que l'émetteur du message est bien celui qu'il prétend être. Elle sert aussi au contrôle d'intégrité pour garantir au récepteur que personne n'a modifié le contenu d'un message lors de son transfert sur le réseau. Elle peut optionnellement être utilisée pour détecter les rejeux. | L'extension d'authentification (AH : Authentication Header) décrite dans le RFC 4302 permet de s'assurer que l'émetteur du message est bien celui qu'il prétend être. Elle sert aussi au contrôle d'intégrité pour garantir au récepteur que personne n'a modifié le contenu d'un message lors de son transfert sur le réseau. Elle peut optionnellement être utilisée pour détecter les rejeux. | ||
| − | Le principe de l'authentification est relativement simple. L'émetteur calcule un authentificateur sur un datagramme et l'émet avec le datagramme sur lequel il porte. Le récepteur récupère cette valeur et vérifie qu'elle est correcte. | + | Le principe de l'authentification est relativement simple. L'émetteur calcule un authentificateur sur un datagramme et l'émet avec le datagramme sur lequel il porte. Le récepteur récupère cette valeur et vérifie qu'elle est correcte. Si un code d'authentification de message <ref>Code d'authentification de message, [https://fr.wikipedia.org/wiki/Code_d%27authentification_de_message Article Wikipedia]</ref> est utilisé, il suffit au récepteur de calculer de son côté le code sur le même datagramme à l'aide de la clé symétrique partagée et de le comparer avec le code reçu. Si le mécanisme de signature numérique est employé, le récepteur doit alors récupérer la signature, la déchiffrer avec la clé publique de l'émetteur et comparer le condensat ainsi obtenu avec celui calculé de son côté sur le datagramme reçu. Si les deux codes, ou les deux condensats diffèrent, soit l'émetteur ne possède pas la bonne clé, soit le message a subi des modifications en chemin. |
L'extension ESP ''Encapsulating Security Payload'' décrite dans le RFC 4303 permet de chiffrer l'ensemble des paquets ou leur partie transport et de garantir l'authentification et l'intégrité de ces paquets. Cette extension permet optionnellement de détecter les rejeux (à condition que le service d'authentification soit assuré) et garantit de façon limitée la confidentialité du flux. | L'extension ESP ''Encapsulating Security Payload'' décrite dans le RFC 4303 permet de chiffrer l'ensemble des paquets ou leur partie transport et de garantir l'authentification et l'intégrité de ces paquets. Cette extension permet optionnellement de détecter les rejeux (à condition que le service d'authentification soit assuré) et garantit de façon limitée la confidentialité du flux. | ||
| − | Pour obtenir ces services de sécurité, il est nécessaire, avant d'émettre un paquet IP sur le réseau, de chiffrer les données à protéger, de calculer un authentificateur, et d'encapsuler ces informations dans l'en-tête de confidentialité ESP. Cela nécessite bien entendu l'existence d'une association de sécurité précisant, entre autres, le ou les | + | Pour obtenir ces services de sécurité, il est nécessaire, avant d'émettre un paquet IP sur le réseau, de chiffrer les données à protéger, de calculer un authentificateur, et d'encapsuler ces informations dans l'en-tête de confidentialité ESP. Cela nécessite bien entendu l'existence d'une association de sécurité précisant, entre autres, le ou les algorithmes de chiffrement, la ou les clés, et un indice de paramètres de sécurité. Pour en savoir plus sur les extensions de sécurité, nous renvoyons le lecteur vers le livre<ref>G. Cizault. livre "IPv6, Théorie et Pratique". [http://livre.g6.asso.fr/index.php/S%C3%A9curit%C3%A9 Chapitre sur la Sécurité]</ref>. |
=== Segment Routing Header (SRH) === | === Segment Routing Header (SRH) === | ||
| − | Cette extension est une des briques qui permet la mise en | + | Cette extension est une des briques qui permet la mise en œuvre de l'ingénierie de trafic et de la qualité de service dans les réseaux IPv6. Certaines applications ont besoin que le délai, le taux de perte des paquets et le débit ne dépassent pas un certain seuil. Par exemple, une session de vidéo-conférence peut nécessiter que le délai de bout en bout reste inférieur à 100 ms, que le débit disponible soit au minimum de 2 Mbit/s et que le taux de perte reste inférieur à 1 %. La solution habituellement mise en œuvre pour le respect de ces métriques de qualité de service est RSVP-TE<ref>Packet Pushers, novembre 2016.[http://packetpushers.net/rsvp-te-protocol-deep-dive/ Deep dive in the RSVP-TE protocol]</ref>. RSVP est un protocole de réservation de ressources sur les routeurs du chemin entre une source et une destination. La composante d'ingénierie de trafic permet notamment de choisir explicitement le chemin qui sera suivi par le paquet. Lorsqu'une application a besoin de réserver des ressources, un circuit MPLS est établi et le protocole RSVP réserve les ressources sur l'ensemble des routeurs qui composent le chemin. La figure 4 résume ce comportement : le nœud A est la source du flot de vidéo-conférence destiné à B. Elle demande l'installation d'un chemin via MPLS. Le contrôleur détermine que le chemin le plus adapté est celui transitant par G,H,I,K,N source de vidéo-conférence. Elle effectue ensuite une réservation de ressource via RSVP. Chacun des routeurs G,H,I,K,N doit accepter la requête. |
| Line 98: | Line 93: | ||
| − | L'inconvénient de cette méthode est qu'avec RSVP, les réservations doivent être fréquemment renouvelées et les routeurs doivent garder des états relatifs à chacun des flots. | + | L'inconvénient de cette méthode est qu'avec RSVP, les réservations doivent être fréquemment renouvelées et les routeurs doivent garder des états relatifs à chacun des flots. À chaque fois qu'un routeur reçoit un paquet, il doit chercher dans la liste des flots le comportement à y associer. Cela limite le passage à l'échelle (le nombre de flots supportés). De plus, l'établissement des circuits MPLS est coûteux en temps, en états, et en communication. Pour finir, si un des nœuds ou des liens qui compose le chemin n'est plus disponible, le temps requis pour établir un nouveau chemin peut être trop important face aux besoins des flots <ref>Cisco, [http://www.segment-routing.net/tutorials/2017-03-06-segment-routing-traffic-engineering-srte/ SR Traffic Engineering]</ref>. |
| − | Le concept de segment routing a été proposé pour palier | + | Le concept de ''segment routing'' a été proposé pour palier ces désavantages. Il permet de réduire l'intelligence des nœuds du réseau. Un contrôleur choisit le chemin qui respecte les besoins de qualité de service du nœud. Le chemin à suivre ainsi que le traitement à associer aux paquets sont ensuite explicitement listés dans leurs en-têtes. Ces traitements à appliquer au paquet sont appelées segments. Un segment peut être l'adresse d'un routeur par lequel le paquet devra transiter, un lien à emprunter ou encore un service fourni par le routeur sur lequel transite le paquet. La séquence de segments que doit suivre le paquet peut être implémentée via une liste de labels MPLS ou, dans le cas d'un réseau IPv6, via l'option ''Segment Routing'' de l'en-tête <ref> Previdi & al. [https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06 IPv6 Segment Routing Header (SRH) (Draft)]</ref>. Contrairement à MPLS, le ''segment routing'' avec IPv6 ne requière pas que tous les nœuds traversés par le paquet soient compatibles avec cette option. Cela permet un déploiement progressif et la traversée de plusieurs types de réseaux. Notons qu'il n'est pas nécessaire d'inscrire l'intégralité du chemin dans la liste. Les règles de routage classique de l'IGP s'appliquent jusqu'au prochain nœud explicitement listé dans l'en-tête. Dans le cas de la figure 5, pour suivre le chemin G,H,I,K,N, il est seulement nécessaire d'ajouter I et B dans la liste. Lorsque le paquet est généré par A, l'adresse de destination est celle de I. Lorsque le paquet atteint I, l'adresse de destination est remplacée par la prochaine dans la liste ; c'est-à-dire B. Le paquet suit le plus court chemin entre I et B ; en l’occurrence I,K,N. Le surcoût induit par la taille de l'extension de l'en-tête est donc limité. |
<center> | <center> | ||
| − | [[image:Moocipv6-act24-SRH-rsvp.png|thumb|center|600px|Figure 5 :Exemple d'utilisation du Segment Routing pour l'ingénierie de trafic et la qualité de service.]] | + | [[image:Moocipv6-act24-SRH-rsvp.png|thumb|center|600px|Figure 5 : Exemple d'utilisation du ''Segment Routing'' pour l'ingénierie de trafic et la qualité de service.]] |
</center> | </center> | ||
| − | Le projet de RFC prévoit qu'un segment soit représenté sur | + | Le projet de RFC prévoit qu'un segment soit représenté sur 128 bits ; c'est-à-dire autant qu'une adresse IPv6. Le nombre de segments inclus dans l'option SRH peut être déduit du champ <tt>Hdr Ext Len</tt> qui indique le nombre d'octets de l'option moins un. Le prochain segment à appliquer est indiqué par le champ <tt>Segments Left</tt> qui indique le nombre de segments restant à appliquer au paquet. Le segment courant est inscrit dans le champ adresse de destination de l'en-tête IPv6. Lorsque le traitement associé à un segment est achevé, le prochain segment à traiter est copié dans le champ adresse de destination et le champ <tt>Segments Left</tt> est décrementé. |
| Line 117: | Line 112: | ||
</center> | </center> | ||
| − | L'extension SRH est très proche de l'en-tête de routage défini dans le RFC 8200 de IPv6. L'en-tête de routage devait notamment permettre le routage à la source (voir la figure 6) qui consiste à lister les routeurs que devaient traverser le paquet au cours de son acheminement. Cette pratique a été dépréciée en 2007 par | + | L'extension SRH est très proche de l'en-tête de routage défini dans le RFC 8200 de IPv6. L'en-tête de routage devait notamment permettre le routage à la source (voir la figure 6) qui consiste à lister les routeurs que devaient traverser le paquet au cours de son acheminement. Cette pratique a été dépréciée en 2007 par le RFC 5095 pour des raisons de sécurité. En effet cela permettait de générer de la congestion sur certains chemins, des attaques de déni de service, des contournements des règles de filtrages de certains pare-feux ou encore d'utiliser des machines publiques accessibles (en DMZ) pour accéder à des machines privées. <ref>P. Biondi et A. Ebalard, CanSecWest, 2017 .[http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf IPv6 Routing Header Security]</ref>. |
| − | Pour être acceptée, l'extension SRH doit donc garantir qu'elle ne serait pas vulnérable à ces attaques. Plusieurs cas d'utilisation sont décrits. Lorsque l'extension SRH est générée au sein du réseau de l'opérateur (e | + | Pour être acceptée, l'extension SRH doit donc garantir qu'elle ne serait pas vulnérable à ces attaques. Plusieurs cas d'utilisation sont décrits. Lorsque l'extension SRH est générée au sein du réseau de l'opérateur (i.e. routeur de bordure), les attaques listées dans le RFC 5095 sont inopérantes. Les routeurs de bordures doivent simplement filtrer les paquets provenant de l'extérieur pour éviter que des hôtes s'attribuent des privilèges ou provoquent de la congestion sur certains liens. Lorsque les SRH sont générées en dehors du réseau de l'opérateur, le projet de RFC prévoit l'utilisation d'un mécanisme d'authentification de l'en-tête défini par le RFC 2104 (option HMAC). La clé de chiffrement de l'en-tête HMAC est distribuée au sein des nœuds autorisés à générer ou manipuler des extensions d'en-têtes SRH. |
== Conclusion == | == Conclusion == | ||
Cette activité vous a décrit les différents mécanismes qui enrichissent les fonctions disponibles au niveau de la couche réseau : routage, fragmentation, sécurité, etc. Ces mécanismes tirent parti de la possibilité d'ajouter des champs supplémentaires à l'en-tête IPv6 grâce aux extensions d'en-tête. Ces extensions sont ajoutées par les extrémités de la communication et sont transparentes pour les routeurs (exception faite des extensions de type ''Hop-by-Hop''). De plus, le mécanisme de chainage par le champ ''Next Header'' permet d'ajouter des extensions de manière souple. | Cette activité vous a décrit les différents mécanismes qui enrichissent les fonctions disponibles au niveau de la couche réseau : routage, fragmentation, sécurité, etc. Ces mécanismes tirent parti de la possibilité d'ajouter des champs supplémentaires à l'en-tête IPv6 grâce aux extensions d'en-tête. Ces extensions sont ajoutées par les extrémités de la communication et sont transparentes pour les routeurs (exception faite des extensions de type ''Hop-by-Hop''). De plus, le mécanisme de chainage par le champ ''Next Header'' permet d'ajouter des extensions de manière souple. | ||
| − | L'usage des extensions est encore assez limité sur l'Internet. Certaines fonctionnalités ont été dépréciées (comme l'extension de routage RH0) et d'autres peinent à se développer (comme la mobilité IPv6). La présence potentielle de ces extensions doit être cependant | + | L'usage des extensions est encore assez limité sur l'Internet. Certaines fonctionnalités ont été dépréciées (comme l'extension de routage RH0) et d'autres peinent à se développer (comme la mobilité IPv6). La présence potentielle de ces extensions doit être cependant prise en compte dans le traitement des paquets, notamment le filtrage sur les valeurs du champ ''Next Header'' de l'en-tête IPv6. |
== Références bibliographiques == | == Références bibliographiques == | ||
| Line 131: | Line 126: | ||
== Pour aller plus loin== | == Pour aller plus loin== | ||
Vous pouvez approfondir vos connaissances en consultant les documents de ce paragraphe. | Vous pouvez approfondir vos connaissances en consultant les documents de ce paragraphe. | ||
| + | |||
RFC et leur analyse par S. Bortzmeyer : | RFC et leur analyse par S. Bortzmeyer : | ||
Latest revision as of 15:01, 15 June 2021
Activité 25 : Le mécanisme d’extension de l'en-tête IPv6
Introduction
Les extensions de l'en-tête IPv6 visent à ajouter des fonctionnalités supplémentaires à l'acheminement d'un paquet dans l'Internet. Ces extensions vont impliquer le traitement de ces fonctionnalités au niveau réseau, soit par le destinataire du paquet IPv6, soit par les routeurs intermédiaires en charge de l’acheminement du paquet IPv6.
De nombreuses extensions ont été définies, afin d'assurer des fonctions comme le routage par la source, la gestion de la fragmentation, la confidentialité des communications (mécanisme ipsec), etc.
Le mécanisme d'extension de l'en-tête IPv6 est assez souple pour pouvoir inclure d'autres fonctionnalités futures. Dans cette activité, nous allons nous intéresser au principe du traitement des extensions au moyen d'exemples simples et démonstratifs de ce mécanisme.
Principe des extensions IPv6
Les extensions peuvent être vues comme un protocole 3.5, entre les couches 3 (réseau) et 4 (transport) du modèle OSI. En effet, à part l'extension de proche-en-proche, qui est traitée par tous les routeurs traversés, les autres extensions ne sont traitées que par le destinataire du paquet (i.e. celui spécifié dans le champ adresse de destination du paquet IPv6). Une extension a une longueur multiple de 8 octets (64 bits). Elle commence par un champ Next header qui définit, sur un octet, le type d'extension ou de protocole qui suit. Pour les extensions de longueur variable, l'octet suivant contient la longueur de l'extension en mots de 8 octets, le premier mot n'étant pas compté. Par exemple, une extension de 16 octets aura une longueur de 1.
Si, d'un point de vue théorique, les extensions sont supérieures aux options d'IPv4, dans la réalité très peu sont utilisées à grande échelle et restent du domaine de la recherche.
Nota : dans la pratique, l'extension la plus couramment rencontrée est probablement l'option de fragmentation à la source. En effet, certains protocoles applicatifs sur UDP, tel que NFS, supposant que la fragmentation existe au niveau réseau, produisent des messages de taille quelconque sans se soucier du MTU. Comme il n'est pas envisageable de modifier ces applications largement déployées, la couche réseau IPv6 doit être capable de gérer la fragmentation. IPv6 impose simplement que cette dernière se fasse à la source.
Une présentation illustrée des extensions IPv6 peut être consultée sur le site de Cisco[1].
Le champ Next Header
Le champ Next Header de l'en-tête IPv6, comme illustré sur la figure 1, identifie généralement le protocole de niveau supérieur comme, par exemple, le transport TCP/UDP. Mais, dans le cas des extensions, plusieurs mécanismes particuliers sont également disponibles parmi la liste suivante :
| valeur | Hexa | Protocole ou Extension |
|---|---|---|
| 0 | 0x00 | Proche-en-proche |
| 4 | 0x04 | IPv4 |
| 6 | 0x06 | TCP |
| 17 | 0x11 | UDP |
| 41 | 0x29 | IPv6 |
| 43 | 0x2b | Routage |
| 44 | 0x2c | Fragmentation |
| 50 | 0x32 | Confidentialité |
| 51 | 0x33 | Authentification |
| 58 | 0x3a | ICMPv6 |
| 59 | 0x3b | Fin des en-têtes |
| 60 | 0x3c | Destination |
| 132 | 0x84 | SCTP |
| 135 | 0x87 | Mobilité |
| 136 | 0x88 | UDP-lite |
| 140 | 0x8c | Shim6 |
Intégration des extensions d’en-tête dans le paquet IPv6
Quand il y a plusieurs extensions dans un même datagramme, les extensions sont placées selon un ordre qui dépend de leur portée :
- extensions impliquant tous les routeurs intermédiaires : Hop-by-Hop ;
- extensions impliquant seulement certains routeurs désignés : Routing ;
- extension impliquant le destinataire : Authentication, Encapsulating Security Payload, Fragmentation, Destination.
La figure 2 montre la souplesse avec laquelle plusieurs extensions peuvent être chaînées. Chaque extension contient dans son en-tête un champ en-tête suivant et un champ longueur. Le premier paquet ne contient pas d'extension ; le champ en-tête suivant pointe sur ICMPv6. Le second paquet ne contient pas d'extension ; le champ en-tête suivant pointe sur TCP. Le troisième paquet contient une extension de protection qui pointe ensuite sur UDP. Dans le dernier paquet, une extension de routage, qui pointe sur une extension de fragmentation, pointe finalement sur ICMPv6.
- L'enchaînement des extensions se fait dans un ordre bien déterminé. Par exemple, une extension concernant tous les routeurs sur le chemin (Hop-by-Hop) devra forcément se trouver en première position. Si elle se trouvait à la suite d'une extension Destination, elle ne pourrait être lue, l'extension Destination n'étant interprétée que par le destinataire du paquet.
- Si cet enchaînement d'extension offre beaucoup plus de souplesse que les options d'IPv4, il rend difficile la lecture des numéros de port. Il faut en effet lire tout l'enchaînement d'extension pour arriver au protocole de niveau 4. Ceci a servi de justification à l'identificateur de flux qui permettait de refléter au niveau 3 un flux particulier et évitait de dérouler l'enchaînement. Bien entendu, les pare-feux devront vérifier les numéros de ports.
- Les extensions peuvent être vues comme un protocole 3.5 (entre la couche 3 et la couche 4). En effet, à part l'extension de "proche en proche", qui est traitée par tous les routeurs traversés, les autres extensions ne sont traitées que par le destinataire du paquet (i.e. celui spécifié dans le champ adresse de destination du paquet IPv6).
Quelques exemples
Fragmentation
Nous avons vu la fragmentation en détail lors de l'activité consacrée à la taille des paquets IPv6. Les points essentiels à rappeler sont que la fragmentation en IPv6 est une fonction d'hôtes exclusivement, et que par souci d'efficacité, l'adaptation de la taille de l'unité de données applicatives en unité de transfert est du ressort de la couche de transport. Cependant, lorsque ce n'est pas possible, en dernier ressort, la fragmentation est faite par IPv6. Les informations pour la fragmentation sont placées dans une extension d'en-tête IPv6 identifiée par la valeur 44. D'un point de vue du codage, l'en-tête et les extensions qui concernent les routeurs intermédiaires (pour l'instant "proche en proche" et "routage par la source") sont recopiées dans chaque fragment, tandis que les autres extensions et l'en-tête de niveau 4 ne seront présents que dans le premier fragment.
La fragmentation en IPv4 n'est pas très performante. Quand un routeur ne peut pas transmettre un paquet à cause de sa trop grande taille, il doit le transmettre en fragments. Comme l'Internet n'est pas fiable, un fragment peut se perdre. Le destinataire ne peut rassembler les fragments. Cela revient à perdre tous les fragments. Il est donc plus efficace de faire les fragments avant la couche IP. Ainsi le fragment devient un paquet IP à la bonne taille. Maintenant, en cas de perte, seul le paquet perdu sera retransmis, évitant ainsi la retransmission de gros blocs de données.
Il est plus intéressant d'adapter la taille des paquets à l'émission. Ceci est fait en utilisant les techniques de découverte du MTU (voir RFC 8201 : Mécanisme de découverte du PMTU). En pratique, une taille de paquets de MTU 1280 octets est une bonne garantie d'acheminement du paquet.
Extensions d'authentification (AH) et de confidentialité (ESP)
L'extension d'authentification (AH : Authentication Header) décrite dans le RFC 4302 permet de s'assurer que l'émetteur du message est bien celui qu'il prétend être. Elle sert aussi au contrôle d'intégrité pour garantir au récepteur que personne n'a modifié le contenu d'un message lors de son transfert sur le réseau. Elle peut optionnellement être utilisée pour détecter les rejeux.
Le principe de l'authentification est relativement simple. L'émetteur calcule un authentificateur sur un datagramme et l'émet avec le datagramme sur lequel il porte. Le récepteur récupère cette valeur et vérifie qu'elle est correcte. Si un code d'authentification de message [2] est utilisé, il suffit au récepteur de calculer de son côté le code sur le même datagramme à l'aide de la clé symétrique partagée et de le comparer avec le code reçu. Si le mécanisme de signature numérique est employé, le récepteur doit alors récupérer la signature, la déchiffrer avec la clé publique de l'émetteur et comparer le condensat ainsi obtenu avec celui calculé de son côté sur le datagramme reçu. Si les deux codes, ou les deux condensats diffèrent, soit l'émetteur ne possède pas la bonne clé, soit le message a subi des modifications en chemin.
L'extension ESP Encapsulating Security Payload décrite dans le RFC 4303 permet de chiffrer l'ensemble des paquets ou leur partie transport et de garantir l'authentification et l'intégrité de ces paquets. Cette extension permet optionnellement de détecter les rejeux (à condition que le service d'authentification soit assuré) et garantit de façon limitée la confidentialité du flux.
Pour obtenir ces services de sécurité, il est nécessaire, avant d'émettre un paquet IP sur le réseau, de chiffrer les données à protéger, de calculer un authentificateur, et d'encapsuler ces informations dans l'en-tête de confidentialité ESP. Cela nécessite bien entendu l'existence d'une association de sécurité précisant, entre autres, le ou les algorithmes de chiffrement, la ou les clés, et un indice de paramètres de sécurité. Pour en savoir plus sur les extensions de sécurité, nous renvoyons le lecteur vers le livre[3].
Segment Routing Header (SRH)
Cette extension est une des briques qui permet la mise en œuvre de l'ingénierie de trafic et de la qualité de service dans les réseaux IPv6. Certaines applications ont besoin que le délai, le taux de perte des paquets et le débit ne dépassent pas un certain seuil. Par exemple, une session de vidéo-conférence peut nécessiter que le délai de bout en bout reste inférieur à 100 ms, que le débit disponible soit au minimum de 2 Mbit/s et que le taux de perte reste inférieur à 1 %. La solution habituellement mise en œuvre pour le respect de ces métriques de qualité de service est RSVP-TE[4]. RSVP est un protocole de réservation de ressources sur les routeurs du chemin entre une source et une destination. La composante d'ingénierie de trafic permet notamment de choisir explicitement le chemin qui sera suivi par le paquet. Lorsqu'une application a besoin de réserver des ressources, un circuit MPLS est établi et le protocole RSVP réserve les ressources sur l'ensemble des routeurs qui composent le chemin. La figure 4 résume ce comportement : le nœud A est la source du flot de vidéo-conférence destiné à B. Elle demande l'installation d'un chemin via MPLS. Le contrôleur détermine que le chemin le plus adapté est celui transitant par G,H,I,K,N source de vidéo-conférence. Elle effectue ensuite une réservation de ressource via RSVP. Chacun des routeurs G,H,I,K,N doit accepter la requête.
L'inconvénient de cette méthode est qu'avec RSVP, les réservations doivent être fréquemment renouvelées et les routeurs doivent garder des états relatifs à chacun des flots. À chaque fois qu'un routeur reçoit un paquet, il doit chercher dans la liste des flots le comportement à y associer. Cela limite le passage à l'échelle (le nombre de flots supportés). De plus, l'établissement des circuits MPLS est coûteux en temps, en états, et en communication. Pour finir, si un des nœuds ou des liens qui compose le chemin n'est plus disponible, le temps requis pour établir un nouveau chemin peut être trop important face aux besoins des flots [5].
Le concept de segment routing a été proposé pour palier ces désavantages. Il permet de réduire l'intelligence des nœuds du réseau. Un contrôleur choisit le chemin qui respecte les besoins de qualité de service du nœud. Le chemin à suivre ainsi que le traitement à associer aux paquets sont ensuite explicitement listés dans leurs en-têtes. Ces traitements à appliquer au paquet sont appelées segments. Un segment peut être l'adresse d'un routeur par lequel le paquet devra transiter, un lien à emprunter ou encore un service fourni par le routeur sur lequel transite le paquet. La séquence de segments que doit suivre le paquet peut être implémentée via une liste de labels MPLS ou, dans le cas d'un réseau IPv6, via l'option Segment Routing de l'en-tête [6]. Contrairement à MPLS, le segment routing avec IPv6 ne requière pas que tous les nœuds traversés par le paquet soient compatibles avec cette option. Cela permet un déploiement progressif et la traversée de plusieurs types de réseaux. Notons qu'il n'est pas nécessaire d'inscrire l'intégralité du chemin dans la liste. Les règles de routage classique de l'IGP s'appliquent jusqu'au prochain nœud explicitement listé dans l'en-tête. Dans le cas de la figure 5, pour suivre le chemin G,H,I,K,N, il est seulement nécessaire d'ajouter I et B dans la liste. Lorsque le paquet est généré par A, l'adresse de destination est celle de I. Lorsque le paquet atteint I, l'adresse de destination est remplacée par la prochaine dans la liste ; c'est-à-dire B. Le paquet suit le plus court chemin entre I et B ; en l’occurrence I,K,N. Le surcoût induit par la taille de l'extension de l'en-tête est donc limité.
Le projet de RFC prévoit qu'un segment soit représenté sur 128 bits ; c'est-à-dire autant qu'une adresse IPv6. Le nombre de segments inclus dans l'option SRH peut être déduit du champ Hdr Ext Len qui indique le nombre d'octets de l'option moins un. Le prochain segment à appliquer est indiqué par le champ Segments Left qui indique le nombre de segments restant à appliquer au paquet. Le segment courant est inscrit dans le champ adresse de destination de l'en-tête IPv6. Lorsque le traitement associé à un segment est achevé, le prochain segment à traiter est copié dans le champ adresse de destination et le champ Segments Left est décrementé.
L'extension SRH est très proche de l'en-tête de routage défini dans le RFC 8200 de IPv6. L'en-tête de routage devait notamment permettre le routage à la source (voir la figure 6) qui consiste à lister les routeurs que devaient traverser le paquet au cours de son acheminement. Cette pratique a été dépréciée en 2007 par le RFC 5095 pour des raisons de sécurité. En effet cela permettait de générer de la congestion sur certains chemins, des attaques de déni de service, des contournements des règles de filtrages de certains pare-feux ou encore d'utiliser des machines publiques accessibles (en DMZ) pour accéder à des machines privées. [7].
Pour être acceptée, l'extension SRH doit donc garantir qu'elle ne serait pas vulnérable à ces attaques. Plusieurs cas d'utilisation sont décrits. Lorsque l'extension SRH est générée au sein du réseau de l'opérateur (i.e. routeur de bordure), les attaques listées dans le RFC 5095 sont inopérantes. Les routeurs de bordures doivent simplement filtrer les paquets provenant de l'extérieur pour éviter que des hôtes s'attribuent des privilèges ou provoquent de la congestion sur certains liens. Lorsque les SRH sont générées en dehors du réseau de l'opérateur, le projet de RFC prévoit l'utilisation d'un mécanisme d'authentification de l'en-tête défini par le RFC 2104 (option HMAC). La clé de chiffrement de l'en-tête HMAC est distribuée au sein des nœuds autorisés à générer ou manipuler des extensions d'en-têtes SRH.
Conclusion
Cette activité vous a décrit les différents mécanismes qui enrichissent les fonctions disponibles au niveau de la couche réseau : routage, fragmentation, sécurité, etc. Ces mécanismes tirent parti de la possibilité d'ajouter des champs supplémentaires à l'en-tête IPv6 grâce aux extensions d'en-tête. Ces extensions sont ajoutées par les extrémités de la communication et sont transparentes pour les routeurs (exception faite des extensions de type Hop-by-Hop). De plus, le mécanisme de chainage par le champ Next Header permet d'ajouter des extensions de manière souple.
L'usage des extensions est encore assez limité sur l'Internet. Certaines fonctionnalités ont été dépréciées (comme l'extension de routage RH0) et d'autres peinent à se développer (comme la mobilité IPv6). La présence potentielle de ces extensions doit être cependant prise en compte dans le traitement des paquets, notamment le filtrage sur les valeurs du champ Next Header de l'en-tête IPv6.
Références bibliographiques
- ↑ Cisco (2006) White paper.IPv6 Extension Headers Review and Considerations
- ↑ Code d'authentification de message, Article Wikipedia
- ↑ G. Cizault. livre "IPv6, Théorie et Pratique". Chapitre sur la Sécurité
- ↑ Packet Pushers, novembre 2016.Deep dive in the RSVP-TE protocol
- ↑ Cisco, SR Traffic Engineering
- ↑ Previdi & al. IPv6 Segment Routing Header (SRH) (Draft)
- ↑ P. Biondi et A. Ebalard, CanSecWest, 2017 .IPv6 Routing Header Security
Pour aller plus loin
Vous pouvez approfondir vos connaissances en consultant les documents de ce paragraphe.
RFC et leur analyse par S. Bortzmeyer :
- RFC 4302 : IP Authentication Header
- RFC 4303 : IP Encapsulating Security Payload (ESP)
- RFC 5095 : Deprecation of Type 0 Routing Headers in IPv6 Specification Analyse
- RFC 7045 : Transmission and Processing of IPv6 Extension Headers Analyse
- RFC 7872 : Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World Analyse
- RFC 8200 : Internet Protocol, Version 6 (IPv6) Specification Analyse
- RFC 8201 : Path MTU Discovery for IP version 6 Analyse
