http://livre.g6.asso.fr/api.php?action=feedcontributions&user=Ptournoux2&feedformat=atom Livre IPv6 - User contributions [en] 2024-03-28T18:13:29Z User contributions MediaWiki 1.25.2 http://livre.g6.asso.fr/index.php?title=MOOC:Taches_Session_3&diff=14926 MOOC:Taches Session 3 2017-04-24T11:07:56Z <p>Ptournoux2: </p> <hr /> <div>&gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Gestion_de_projet|Gestion de projet]] &gt; [[MOOC:Taches_Session_3 |Tâches session 3]] <br /> ----<br /> {| border=&quot;1&quot; cellpadding=&quot;10&quot; cellspacing=&quot;0&quot;<br /> | style=&quot;background-color: #F99;&quot; | A faire<br /> | style=&quot;background-color: #FAA21A;&quot; | Affecté<br /> | style=&quot;background-color: #FFF200;&quot; | En cours<br /> | style=&quot;background-color: #CCF;&quot; | A valider<br /> | style=&quot;background-color: #77FF77;&quot; | OK<br /> |}<br /> <br /> {| border=&quot;1&quot; cellpadding=&quot;8&quot; cellspacing=&quot;1&quot;<br /> ! #<br /> ! Objet<br /> ! Intitulé Tâche<br /> ! Priorité<br /> ! Intervenants <br /> ! Status<br /> ! Planification<br /> |- <br /> | T01<br /> | Vidéos<br /> | [[MOOC:Session3_Corrections_Videos|Correction video A15]]<br /> | P1<br /> | BS<br /> | style=&quot;background-color: #FFF200;&quot; | En cours<br /> | Contact pris avec Corolia<br /> |- <br /> | T02<br /> | Vidéos<br /> | [[MOOC:Session3_Corrections_Videos|Correction video A31]]<br /> | P1<br /> | BS<br /> | style=&quot;background-color: #FFF200;&quot; | En cours<br /> | Contact pris avec Corolia<br /> |- style=&quot;color: #ccc;&quot;<br /> | T03<br /> | Vidéos<br /> | Nouvelle vidéo A14<br /> | P3<br /> | <br /> | <br /> | Contenu complexe + Etude de cas à intégrer différemment <br /> |- style=&quot;color: #999;&quot; <br /> | T04<br /> | Vidéos<br /> | Refonte charte graphique<br /> | P2<br /> | <br /> | <br /> | <br /> |- <br /> | T05<br /> | Support Cours<br /> | [[MOOC:Session3-Relecture_Support|Relectures croisées]]<br /> | P1<br /> | BS: Séq 1&lt;br&gt;JG: Séq 2&lt;br&gt;JL: Séq 3&lt;br&gt;JPR: Séq 4<br /> | style=&quot;background-color: #FFF200;&quot; | En cours<br /> | <br /> |- style=&quot;color: #999;&quot; <br /> | T06<br /> | Support Cours<br /> | Refonte charte graphique<br /> | P2<br /> | <br /> | <br /> | A mutualiser avec T04<br /> |- <br /> | T07<br /> | Support Cours<br /> | Segment Routing en A24<br /> | P1<br /> | Pierre Ugo<br /> | style=&quot;background-color: #CCF;&quot; | A valider<br /> | <br /> |- <br /> | T08<br /> | Support TP<br /> |[[MOOC:Ateliers|Revoir la scénarisation des TPs]] <br /> | P1<br /> | PA<br /> | style=&quot;background-color: #CCF;&quot; | A valider<br /> | Scénario pour février, test et rédaction après T09 <br /> |- <br /> | T09<br /> | Plateforme TP<br /> | Mise à jour de l'image<br /> | P1<br /> | JPR<br /> | style=&quot;background-color: #FFF200;&quot; | En cours<br /> | Démarrage en février<br /> |- style=&quot;color: #ccc;&quot;<br /> | T10<br /> | Plateforme TP<br /> | Passage en 32b<br /> | P3<br /> | <br /> | <br /> | <br /> |- style=&quot;color: #999;&quot;<br /> | T11<br /> | Plateforme TP<br /> | Containerisation des guests<br /> | P2<br /> | <br /> | <br /> | Projet étudiant au premier semestre ?<br /> |- style=&quot;color: #ccc;&quot;<br /> | T12<br /> | Plateforme TP<br /> | Containerisation du host<br /> | P3<br /> | <br /> | <br /> | <br /> |- style=&quot;color: #ccc;&quot;<br /> | T13<br /> | Plateforme TP<br /> | IPv6Lab-as-a-Service<br /> | P3<br /> | <br /> | <br /> | <br /> |- <br /> | T14<br /> | Evaluations<br /> | [[MOOC:Session3-Alignement_Evaluations|Alignement avec les objectifs pédagogiques]]<br /> | P1<br /> | BS<br /> | style=&quot;background-color: #FFF200;&quot; | En cours<br /> | <br /> |- <br /> | T15<br /> | Evaluations<br /> | [[MOOC:Session3-Alignement_Evaluations|Revoir la progressivité des évaluations]]<br /> | P1<br /> | BS<br /> | style=&quot;background-color: #FFF200;&quot; | En cours<br /> | Des questions à revoir, Problème des inputs adresses IPv6 (filtrer les espaces)<br /> |- style=&quot;color: #999;&quot; <br /> | T16<br /> | Evaluations<br /> | [[MOOC:Session3-Alignement_Evaluations| Annoncer le temps moyen de réalisation d’un exercice]]<br /> | P3<br /> | <br /> |<br /> | <br /> |- <br /> | T17<br /> | Evaluations<br /> | Recette des évaluations<br /> | P1<br /> | VL<br /> | style=&quot;background-color: #FAA21A;&quot; |Planifié<br /> | Suite au passage en prod (~30mars)<br /> |- style=&quot;color: #ccc;&quot; <br /> | T18<br /> | Support cours<br /> | A écrire [[MOOC:Activité 35| Activité 35]]<br /> | P3<br /> | <br /> |<br /> | Sécuriser votre réseau IPv6<br /> |}</div> Ptournoux2 http://livre.g6.asso.fr/index.php?title=MOOC:Taches_Session_3&diff=14925 MOOC:Taches Session 3 2017-04-24T11:07:13Z <p>Ptournoux2: </p> <hr /> <div>&gt; [[MOOC:Accueil|MOOC]]&gt;[[MOOC:Gestion_de_projet|Gestion de projet]] &gt; [[MOOC:Taches_Session_3 |Tâches session 3]] <br /> ----<br /> {| border=&quot;1&quot; cellpadding=&quot;10&quot; cellspacing=&quot;0&quot;<br /> | style=&quot;background-color: #F99;&quot; | A faire<br /> | style=&quot;background-color: #FAA21A;&quot; | Affecté<br /> | style=&quot;background-color: #FFF200;&quot; | En cours<br /> | style=&quot;background-color: #CCF;&quot; | A valider<br /> | style=&quot;background-color: #77FF77;&quot; | OK<br /> |}<br /> <br /> {| border=&quot;1&quot; cellpadding=&quot;8&quot; cellspacing=&quot;1&quot;<br /> ! #<br /> ! Objet<br /> ! Intitulé Tâche<br /> ! Priorité<br /> ! Intervenants <br /> ! Status<br /> ! Planification<br /> |- <br /> | T01<br /> | Vidéos<br /> | [[MOOC:Session3_Corrections_Videos|Correction video A15]]<br /> | P1<br /> | BS<br /> | style=&quot;background-color: #FFF200;&quot; | En cours<br /> | Contact pris avec Corolia<br /> |- <br /> | T02<br /> | Vidéos<br /> | [[MOOC:Session3_Corrections_Videos|Correction video A31]]<br /> | P1<br /> | BS<br /> | style=&quot;background-color: #FFF200;&quot; | En cours<br /> | Contact pris avec Corolia<br /> |- style=&quot;color: #ccc;&quot;<br /> | T03<br /> | Vidéos<br /> | Nouvelle vidéo A14<br /> | P3<br /> | <br /> | <br /> | Contenu complexe + Etude de cas à intégrer différemment <br /> |- style=&quot;color: #999;&quot; <br /> | T04<br /> | Vidéos<br /> | Refonte charte graphique<br /> | P2<br /> | <br /> | <br /> | <br /> |- <br /> | T05<br /> | Support Cours<br /> | [[MOOC:Session3-Relecture_Support|Relectures croisées]]<br /> | P1<br /> | BS: Séq 1&lt;br&gt;JG: Séq 2&lt;br&gt;JL: Séq 3&lt;br&gt;JPR: Séq 4<br /> | style=&quot;background-color: #FFF200;&quot; | En cours<br /> | <br /> |- style=&quot;color: #999;&quot; <br /> | T06<br /> | Support Cours<br /> | Refonte charte graphique<br /> | P2<br /> | <br /> | <br /> | A mutualiser avec T04<br /> |- <br /> | T07<br /> | Support Cours<br /> | Segment Routing en A24<br /> | P1<br /> | Pierre Ugo<br /> | style=&quot;background-color: #FFF200;&quot; | A relire<br /> | <br /> |- <br /> | T08<br /> | Support TP<br /> |[[MOOC:Ateliers|Revoir la scénarisation des TPs]] <br /> | P1<br /> | PA<br /> | style=&quot;background-color: #CCF;&quot; | A valider<br /> | Scénario pour février, test et rédaction après T09 <br /> |- <br /> | T09<br /> | Plateforme TP<br /> | Mise à jour de l'image<br /> | P1<br /> | JPR<br /> | style=&quot;background-color: #FFF200;&quot; | En cours<br /> | Démarrage en février<br /> |- style=&quot;color: #ccc;&quot;<br /> | T10<br /> | Plateforme TP<br /> | Passage en 32b<br /> | P3<br /> | <br /> | <br /> | <br /> |- style=&quot;color: #999;&quot;<br /> | T11<br /> | Plateforme TP<br /> | Containerisation des guests<br /> | P2<br /> | <br /> | <br /> | Projet étudiant au premier semestre ?<br /> |- style=&quot;color: #ccc;&quot;<br /> | T12<br /> | Plateforme TP<br /> | Containerisation du host<br /> | P3<br /> | <br /> | <br /> | <br /> |- style=&quot;color: #ccc;&quot;<br /> | T13<br /> | Plateforme TP<br /> | IPv6Lab-as-a-Service<br /> | P3<br /> | <br /> | <br /> | <br /> |- <br /> | T14<br /> | Evaluations<br /> | [[MOOC:Session3-Alignement_Evaluations|Alignement avec les objectifs pédagogiques]]<br /> | P1<br /> | BS<br /> | style=&quot;background-color: #FFF200;&quot; | En cours<br /> | <br /> |- <br /> | T15<br /> | Evaluations<br /> | [[MOOC:Session3-Alignement_Evaluations|Revoir la progressivité des évaluations]]<br /> | P1<br /> | BS<br /> | style=&quot;background-color: #FFF200;&quot; | En cours<br /> | Des questions à revoir, Problème des inputs adresses IPv6 (filtrer les espaces)<br /> |- style=&quot;color: #999;&quot; <br /> | T16<br /> | Evaluations<br /> | [[MOOC:Session3-Alignement_Evaluations| Annoncer le temps moyen de réalisation d’un exercice]]<br /> | P3<br /> | <br /> |<br /> | <br /> |- <br /> | T17<br /> | Evaluations<br /> | Recette des évaluations<br /> | P1<br /> | VL<br /> | style=&quot;background-color: #FAA21A;&quot; |Planifié<br /> | Suite au passage en prod (~30mars)<br /> |- style=&quot;color: #ccc;&quot; <br /> | T18<br /> | Support cours<br /> | A écrire [[MOOC:Activité 35| Activité 35]]<br /> | P3<br /> | <br /> |<br /> | Sécuriser votre réseau IPv6<br /> |}</div> Ptournoux2 http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act24-s6&diff=14924 MOOC:Compagnon Act24-s6 2017-04-24T11:05:41Z <p>Ptournoux2: /* Segment Routing Header (SRH) */</p> <hr /> <div>__NOTOC__ <br /> =Activité 24 : Le mécanisme d’extension de l'en-tête IPv6=<br /> <br /> == Introduction ==<br /> <br /> 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 :<br /> * soit par le destinataire du paquet IPv6,<br /> * soit par les routeurs intermédiaires en charge de l’acheminement du paquet IPv6.<br /> <br /> De nombreuses extensions ont été définies, afin d'assurer des fonctions comme : <br /> * le routage par la source,<br /> * la gestion de la fragmentation,<br /> * la confidentialité des communications (mécanisme ''ipsec''),<br /> * etc. <br /> <br /> 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.<br /> <br /> == Principe des extensions IPv6==<br /> <br /> 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).<br /> Une extension a une longueur multiple de 8 octets (64 bits). Elle commence par un champ &lt;tt&gt;Next header&lt;/tt&gt; qui définit sur 1 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.<br /> <br /> 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.<br /> <br /> '''''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.''<br /> <br /> Une présentation illustrée des extensionsIPv6 peut être consultée sur le site de Cisco&lt;ref&gt;Cisco (2006) White paper.[http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html IPv6 Extension Headers Review and Considerations]&lt;/ref&gt;.<br /> <br /> == Le champ ''Next Header'' ==<br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_ipv6_header_next-header_v02.jpg|thumb|right|300px|Figure 1 : Localisation du champ &lt;tt&gt;Next Header&lt;/tt&gt; dans l'en-tête IPv6.]]<br /> &lt;/center&gt;<br /> Le champ &lt;tt&gt;Next Header&lt;/tt&gt; 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 :<br /> &lt;center&gt;{{MOOC_Valeurs_du_champ_en-tête_suivant}}<br /> &lt;/center&gt;<br /> <br /> == Intégration des extensions d’en-tête dans le paquet IPv6==<br /> 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: <br /> * extensions impliquant tous les routeurs intermédiaires : ''Hop-by-Hop'' ;<br /> * extensions impliquant seulement certains routeurs désignés : ''Routing'' ;<br /> * extension impliquant le destinataire : ''Authentication'', ''Encapsulating Security Payload'', Fragmentation, Destination.<br /> <br /> <br /> 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 &lt;tt&gt;en-tête suivant&lt;/tt&gt; et un champ &lt;tt&gt;longueur&lt;/tt&gt;. Le premier paquet ne contient pas d'extension ; le champ &lt;tt&gt;en-tête suivant&lt;/tt&gt; pointe sur ICMPv6. Le second paquet ne contient pas d'extension ; le champ &lt;tt&gt;en-tête suivant&lt;/tt&gt; 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. <br /> * 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.<br /> * 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. <br /> * Les extensions peuvent être vues comme un protocole 3.5 (entre la couche 3 et la couche 4). En effet, à part l'extension de &quot;proche en proche&quot;, 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 &lt;tt&gt;adresse de destination&lt;/tt&gt; du paquet IPv6). <br /> <br /> &lt;center&gt;<br /> [[image:2015_10_10_extensions_IPv6_v01.jpg|thumb|center|600px|Figure 2 : Enchaînement d'extensions.]]<br /> &lt;/center&gt;<br /> <br /> == Quelques exemples ==<br /> <br /> === Fragmentation ===<br /> La fragmentation, telle qu'elle est pratiquée dans IPv4, n'est pas très performante. Initialement, elle servait à rendre transparente les limitations physiques des supports de transmission. Dans IPv4, quand un routeur ne peut pas transmettre un paquet à cause de sa trop grande taille, et si le bit DF ''don't fragment'' est à 0, il découpe l'information à transmettre en fragments. Or, le réseau IP étant un réseau à datagrammes, il n'y a pas de possibilité de contrôler les fragments. Deux fragments successifs peuvent prendre deux chemins différents et, par conséquent, seul le destinataire peut effectuer le ré-assemblage. En conséquence, après la traversée d'un lien impliquant une fragmentation, le reste du réseau ne voit passer que des paquets de taille réduite. <br /> <br /> 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 1981 : Mécanisme de découverte du PMTU). En pratique, une taille de paquets de 1 500 octets est presque universelle.<br /> <br /> Il existe pourtant des cas où la fragmentation est nécessaire. Ainsi, une application telle que NFS sur UDP suppose que la fragmentation existe et produit des messages de taille quelconque. Comme on ne veut pas modifier ces applications, la couche réseau d'IPv6 doit aussi être capable de gérer la fragmentation. Pour réduire le travail des routeurs intermédiaires, la fragmentation se fera au niveau de la source et le ré-assemblage par le destinataire. Les informations utiles pour ces mécanismes (identification du paquet fragmenté, place du fragment) sont transportées dans une extension de fragmentation, représentée dans la figure 3. <br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_PMTU_5_v01.jpg|thumb|center|600px|Figure 3 : Format de l'extension de fragmentation.]]<br /> &lt;/center&gt;<br /> <br /> * Le champ longueur de l'extension est remplacé par un champ réservé, positionné pour l'instant à 0. Un champ de longueur est, car l'extension tient sur un seul mot de 64 bits et le premier mot n'est pas compté dans le calcul de longueur des extensions.<br /> * Le &lt;tt&gt;fragment offset&lt;/tt&gt; indique, lors du ré-assemblage, la position à laquelle les données du fragment doivent s'insérer. Ceci permet de résoudre les problèmes dus au déséquencement éventuel des datagrammes. Ce champ étant sur 13 bits, la taille des fragments, excepté le dernier, doit être multiple de 8 octets (alignement sur frontière de mots de 64 bits),<br /> * Le bit &lt;tt&gt;M&lt;/tt&gt; (More data) est à 1 sur les fragments intermédiaires et à 0 sur le fragment final,<br /> * Le champ &lt;tt&gt;identification&lt;/tt&gt; permet de repérer les fragments appartenant à un même paquet initial pour une source et une destination données.<br /> <br /> Le bit DF (Don't Fragment), de l'en-tête IPv4 n'est plus nécessaire. Si un paquet est trop grand, il y aura rejet par le routeur et émission d'un message ICMP.<br /> <br /> Dans IPv6, 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 les autres extensions et l'en-tête de niveau 4 ne seront présents que dans le premier fragment.<br /> <br /> Le mécanisme de gestion de la taille d'un paquet IPv6, selon les différents cas possibles, est approfondi dans l'activité suivante.<br /> <br /> === Extensions d'authentification (AH) et de confidentialité (ESP) ===<br /> <br /> 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.<br /> <br /> 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. C'est-à-dire, si un code d'authentification de message &lt;ref&gt;Code d'authentification de message, [https://fr.wikipedia.org/wiki/Code_d%27authentification_de_message Article Wikipedia]&lt;/ref&gt; est utilisé, il lui suffit 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.<br /> <br /> 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.<br /> <br /> 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 algorithme(s) de chiffrement, la ou les clé(s), et un indice de paramètres de sécurité.<br /> <br /> === Segment Routing Header (SRH) ===<br /> <br /> Cette extension est une des briques qui permet la mise en oeuvre 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 à 100ms, que le débit disponible soit au minimum de 2mbit/s et que le taux de perte reste inférieur à 1%. La solution habituellement mise en oeuvre pour le respect de ces métriques de qualité de service est RSVP-TE&lt;ref&gt;Packet Pushers, Novembre 2016 .[http://packetpushers.net/rsvp-te-protocol-deep-dive/ Deep dive in the RSVP-TE protocol]&lt;/ref&gt;. 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 suivit 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 doivent accepter la requête.<br /> <br /> <br /> <br /> &lt;center&gt;<br /> [[image:Moocipv6-act24-SRH-rsvp2.png|thumb|center|600px|Figure 4 : Exemple d'utilisation de RSVP-TE pour assurer la qualité de service.]]<br /> &lt;/center&gt;<br /> <br /> <br /> 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. A 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 équipements 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 [[http://www.segment-routing.net/tutorials/2017-03-06-segment-routing-traffic-engineering-srte/]].<br /> <br /> Le concept de segment routing a été proposé pour palier à ces désavantages. Il permet de réduire l'intelligence des équipements du réseau. Un contrôleur choisi le chemin qui respecte les besoins de qualité de service du noeud. Le chemin à suivre ainsi que le traitement à associer aux paquets sont ensuite explicitement listés dans leurs entê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 à empreinter ou encore un service fournit 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 label MPLS ou dans le cas d'en réseau IPv6 via l'option Segment Routing de l'entête [https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06]. Contrairement à MPLS, le segment routing avec IPv6 ne requière pas que tous les équipements traversés par le paquet soient compatibles avec cette option. Cela permet un déploiement progressif et de traverser 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 routage classique de l'IGP s'appliquent le prochain nœud explicitement listés dans l'entê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.a.d. 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'entête est donc limité.<br /> <br /> <br /> <br /> &lt;center&gt;<br /> [[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.]]<br /> &lt;/center&gt;<br /> <br /> <br /> <br /> Le projet de RFC [https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06] prévoit qu'un segment soit représenté sur 128bit, c.a.d. autant qu'une adresse IPv6. Le nombre de segments inclus dans l'option SRH peut être déduit du champs Hdr Ext Len qui indique le nombre d'octets de l'option moins un. Le prochain segment à appliquer est indiqué par le champs Segments Left qui indique nombre de segments restant à appliquer au paquet. Le segment courant est inscrit dans le champs adresse de destination de l'entête IPv6. Lorsque le traitement associé à un segment est achevé, le prochain segment à traiter est copié dans le champs adresse de destination et le champs Segments Left est décrementé.<br /> <br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_IPv6_extension_routage_v02.jpg|thumb|center|400px|Figure 5 : Extension de routage par la source.]]<br /> &lt;/center&gt;<br /> <br /> L'option SRH est très proche de l'entête de routage défini dans la RFC2460 de IPv6. L'entête de routage devait notamment permettre le routage à la source 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 la 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, de contourner les règles de filtrages de certains pare-feu ou encore d'utiliser des machines publiques accessibles (en DMZ) pour accéder à des machines privées. &lt;ref&gt;Philippe BIONDI et Arnaud EBALARD, CanSecWest, 2017 .[http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf IPv6 Routing Reader Security]&lt;/ref&gt;.<br /> <br /> Pour être accepté, l'option SRH devait donc garantir qu'elle ne serait pas vulnérable à ces attaques. Plusieurs cas d'utilisation sont décrits. Lorsque la SRH est générée au sein du réseau de l'opérateur (e.g. routeur de bordure) les attaques listées dans la RFC5095 sont inopérantes. Les routeurs de bordures doivent simplement filtrer les paquets venus de l'extérieur pour éviter de hôtes s'attribuent des privilèges ou provoque de la congestion sur certains lien. Lorsque les SRH sont générées en dehors du réseau de l'opérateur, la projet de RFC prévoit l'utilisation d'un mécanisme d'authentification de l'entête [RFC2104] (option HMAC). La clé de chiffrement de l'entête HMAC est distribuée au sein des noeuds autorisés à générer ou manipuler des entêtes SRH.<br /> <br /> == Conclusion ==<br /> 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 communications 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.<br /> <br /> 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 pris en compte dans le traitement des paquets, notamment le filtrage sur les valeurs du champ ''Next Header'' de l'en-tête IPv6.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin==<br /> Vous pouvez approfondir vos connaissances en consultant les documents de ce paragraphe.<br /> RFC et leur analyse par S. Bortzmeyer :<br /> * RFC 1981 : Path MTU Discovery for IP version 6<br /> * RFC 2460 : Internet Protocol, Version 6 (IPv6) Specification [http://www.bortzmeyer.org/2460.html Analyse]<br /> * RFC 4302 : IP Authentication Header<br /> * RFC 4303 : IP Encapsulating Security Payload (ESP)<br /> * RFC 5095 : Deprecation of Type 0 Routing Headers in IPv6 Specification [http://www.bortzmeyer.org/5095.html Analyse]<br /> * RFC 7045 : Transmission and Processing of IPv6 Extension Headers [http://www.bortzmeyer.org/7045.html Analyse]<br /> * RFC 7872 : Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World [http://www.bortzmeyer.org/7872.html Analyse]<br /> * [http://livre.g6.asso.fr/index.php/S%C3%A9curit%C3%A9 Chapitre Sécurité du livre &quot;IPv6, Théorie et Pratique&quot;]</div> Ptournoux2 http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act24-s6&diff=14923 MOOC:Compagnon Act24-s6 2017-04-24T11:02:57Z <p>Ptournoux2: /* Segment Routing Header (SRH) */</p> <hr /> <div>__NOTOC__ <br /> =Activité 24 : Le mécanisme d’extension de l'en-tête IPv6=<br /> <br /> == Introduction ==<br /> <br /> 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 :<br /> * soit par le destinataire du paquet IPv6,<br /> * soit par les routeurs intermédiaires en charge de l’acheminement du paquet IPv6.<br /> <br /> De nombreuses extensions ont été définies, afin d'assurer des fonctions comme : <br /> * le routage par la source,<br /> * la gestion de la fragmentation,<br /> * la confidentialité des communications (mécanisme ''ipsec''),<br /> * etc. <br /> <br /> 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.<br /> <br /> == Principe des extensions IPv6==<br /> <br /> 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).<br /> Une extension a une longueur multiple de 8 octets (64 bits). Elle commence par un champ &lt;tt&gt;Next header&lt;/tt&gt; qui définit sur 1 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.<br /> <br /> 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.<br /> <br /> '''''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.''<br /> <br /> Une présentation illustrée des extensionsIPv6 peut être consultée sur le site de Cisco&lt;ref&gt;Cisco (2006) White paper.[http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html IPv6 Extension Headers Review and Considerations]&lt;/ref&gt;.<br /> <br /> == Le champ ''Next Header'' ==<br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_ipv6_header_next-header_v02.jpg|thumb|right|300px|Figure 1 : Localisation du champ &lt;tt&gt;Next Header&lt;/tt&gt; dans l'en-tête IPv6.]]<br /> &lt;/center&gt;<br /> Le champ &lt;tt&gt;Next Header&lt;/tt&gt; 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 :<br /> &lt;center&gt;{{MOOC_Valeurs_du_champ_en-tête_suivant}}<br /> &lt;/center&gt;<br /> <br /> == Intégration des extensions d’en-tête dans le paquet IPv6==<br /> 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: <br /> * extensions impliquant tous les routeurs intermédiaires : ''Hop-by-Hop'' ;<br /> * extensions impliquant seulement certains routeurs désignés : ''Routing'' ;<br /> * extension impliquant le destinataire : ''Authentication'', ''Encapsulating Security Payload'', Fragmentation, Destination.<br /> <br /> <br /> 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 &lt;tt&gt;en-tête suivant&lt;/tt&gt; et un champ &lt;tt&gt;longueur&lt;/tt&gt;. Le premier paquet ne contient pas d'extension ; le champ &lt;tt&gt;en-tête suivant&lt;/tt&gt; pointe sur ICMPv6. Le second paquet ne contient pas d'extension ; le champ &lt;tt&gt;en-tête suivant&lt;/tt&gt; 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. <br /> * 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.<br /> * 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. <br /> * Les extensions peuvent être vues comme un protocole 3.5 (entre la couche 3 et la couche 4). En effet, à part l'extension de &quot;proche en proche&quot;, 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 &lt;tt&gt;adresse de destination&lt;/tt&gt; du paquet IPv6). <br /> <br /> &lt;center&gt;<br /> [[image:2015_10_10_extensions_IPv6_v01.jpg|thumb|center|600px|Figure 2 : Enchaînement d'extensions.]]<br /> &lt;/center&gt;<br /> <br /> == Quelques exemples ==<br /> <br /> === Fragmentation ===<br /> La fragmentation, telle qu'elle est pratiquée dans IPv4, n'est pas très performante. Initialement, elle servait à rendre transparente les limitations physiques des supports de transmission. Dans IPv4, quand un routeur ne peut pas transmettre un paquet à cause de sa trop grande taille, et si le bit DF ''don't fragment'' est à 0, il découpe l'information à transmettre en fragments. Or, le réseau IP étant un réseau à datagrammes, il n'y a pas de possibilité de contrôler les fragments. Deux fragments successifs peuvent prendre deux chemins différents et, par conséquent, seul le destinataire peut effectuer le ré-assemblage. En conséquence, après la traversée d'un lien impliquant une fragmentation, le reste du réseau ne voit passer que des paquets de taille réduite. <br /> <br /> 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 1981 : Mécanisme de découverte du PMTU). En pratique, une taille de paquets de 1 500 octets est presque universelle.<br /> <br /> Il existe pourtant des cas où la fragmentation est nécessaire. Ainsi, une application telle que NFS sur UDP suppose que la fragmentation existe et produit des messages de taille quelconque. Comme on ne veut pas modifier ces applications, la couche réseau d'IPv6 doit aussi être capable de gérer la fragmentation. Pour réduire le travail des routeurs intermédiaires, la fragmentation se fera au niveau de la source et le ré-assemblage par le destinataire. Les informations utiles pour ces mécanismes (identification du paquet fragmenté, place du fragment) sont transportées dans une extension de fragmentation, représentée dans la figure 3. <br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_PMTU_5_v01.jpg|thumb|center|600px|Figure 3 : Format de l'extension de fragmentation.]]<br /> &lt;/center&gt;<br /> <br /> * Le champ longueur de l'extension est remplacé par un champ réservé, positionné pour l'instant à 0. Un champ de longueur est, car l'extension tient sur un seul mot de 64 bits et le premier mot n'est pas compté dans le calcul de longueur des extensions.<br /> * Le &lt;tt&gt;fragment offset&lt;/tt&gt; indique, lors du ré-assemblage, la position à laquelle les données du fragment doivent s'insérer. Ceci permet de résoudre les problèmes dus au déséquencement éventuel des datagrammes. Ce champ étant sur 13 bits, la taille des fragments, excepté le dernier, doit être multiple de 8 octets (alignement sur frontière de mots de 64 bits),<br /> * Le bit &lt;tt&gt;M&lt;/tt&gt; (More data) est à 1 sur les fragments intermédiaires et à 0 sur le fragment final,<br /> * Le champ &lt;tt&gt;identification&lt;/tt&gt; permet de repérer les fragments appartenant à un même paquet initial pour une source et une destination données.<br /> <br /> Le bit DF (Don't Fragment), de l'en-tête IPv4 n'est plus nécessaire. Si un paquet est trop grand, il y aura rejet par le routeur et émission d'un message ICMP.<br /> <br /> Dans IPv6, 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 les autres extensions et l'en-tête de niveau 4 ne seront présents que dans le premier fragment.<br /> <br /> Le mécanisme de gestion de la taille d'un paquet IPv6, selon les différents cas possibles, est approfondi dans l'activité suivante.<br /> <br /> === Extensions d'authentification (AH) et de confidentialité (ESP) ===<br /> <br /> 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.<br /> <br /> 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. C'est-à-dire, si un code d'authentification de message &lt;ref&gt;Code d'authentification de message, [https://fr.wikipedia.org/wiki/Code_d%27authentification_de_message Article Wikipedia]&lt;/ref&gt; est utilisé, il lui suffit 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.<br /> <br /> 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.<br /> <br /> 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 algorithme(s) de chiffrement, la ou les clé(s), et un indice de paramètres de sécurité.<br /> <br /> === Segment Routing Header (SRH) ===<br /> <br /> Cette extension est une des briques qui permet la mise en oeuvre 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 à 100ms, que le débit disponible soit au minimum de 2mbit/s et que le taux de perte reste inférieur à 1%. La solution habituellement mise en oeuvre pour le respect de ces métriques de qualité de service est RSVP-TE&lt;ref&gt;Packet Pushers, Novembre 2016 .[http://packetpushers.net/rsvp-te-protocol-deep-dive/ Deep dive in the RSVP-TE protocol]&lt;/ref&gt;. 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 suivit 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 doivent accepter la requête.<br /> <br /> <br /> <br /> &lt;center&gt;<br /> [[image:Moocipv6-act24-SRH-rsvp2.png|thumb|center|400px|Figure 4 : Exemple d'utilisation de RSVP-TE pour assurer la qualité de service.]]<br /> &lt;/center&gt;<br /> <br /> <br /> 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. A 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 équipements 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 [[http://www.segment-routing.net/tutorials/2017-03-06-segment-routing-traffic-engineering-srte/]].<br /> <br /> Le concept de segment routing a été proposé pour palier à ces désavantages. Il permet de réduire l'intelligence des équipements du réseau. Un contrôleur choisi le chemin qui respecte les besoins de qualité de service du noeud. Le chemin à suivre ainsi que le traitement à associer aux paquets sont ensuite explicitement listés dans leurs entê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 à empreinter ou encore un service fournit 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 label MPLS ou dans le cas d'en réseau IPv6 via l'option Segment Routing de l'entête [https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06]. Contrairement à MPLS, le segment routing avec IPv6 ne requière pas que tous les équipements traversés par le paquet soient compatibles avec cette option. Cela permet un déploiement progressif et de traverser 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 routage classique de l'IGP s'appliquent le prochain nœud explicitement listés dans l'entê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.a.d. 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'entête est donc limité.<br /> <br /> <br /> <br /> &lt;center&gt;<br /> [[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.]]<br /> &lt;/center&gt;<br /> <br /> <br /> <br /> Le projet de RFC [https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06] prévoit qu'un segment soit représenté sur 128bit, c.a.d. autant qu'une adresse IPv6. Le nombre de segments inclus dans l'option SRH peut être déduit du champs Hdr Ext Len qui indique le nombre d'octets de l'option moins un. Le prochain segment à appliquer est indiqué par le champs Segments Left qui indique nombre de segments restant à appliquer au paquet. Le segment courant est inscrit dans le champs adresse de destination de l'entête IPv6. Lorsque le traitement associé à un segment est achevé, le prochain segment à traiter est copié dans le champs adresse de destination et le champs Segments Left est décrementé.<br /> <br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_IPv6_extension_routage_v02.jpg|thumb|center|400px|Figure 5 : Extension de routage par la source.]]<br /> &lt;/center&gt;<br /> <br /> L'option SRH est très proche de l'entête de routage défini dans la RFC2460 de IPv6. L'entête de routage devait notamment permettre le routage à la source 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 la 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, de contourner les règles de filtrages de certains pare-feu ou encore d'utiliser des machines publiques accessibles (en DMZ) pour accéder à des machines privées. &lt;ref&gt;Philippe BIONDI et Arnaud EBALARD, CanSecWest, 2017 .[http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf IPv6 Routing Reader Security]&lt;/ref&gt;.<br /> <br /> Pour être accepté, l'option SRH devait donc garantir qu'elle ne serait pas vulnérable à ces attaques. Plusieurs cas d'utilisation sont décrits. Lorsque la SRH est générée au sein du réseau de l'opérateur (e.g. routeur de bordure) les attaques listées dans la RFC5095 sont inopérantes. Les routeurs de bordures doivent simplement filtrer les paquets venus de l'extérieur pour éviter de hôtes s'attribuent des privilèges ou provoque de la congestion sur certains lien. Lorsque les SRH sont générées en dehors du réseau de l'opérateur, la projet de RFC prévoit l'utilisation d'un mécanisme d'authentification de l'entête [RFC2104] (option HMAC). La clé de chiffrement de l'entête HMAC est distribuée au sein des noeuds autorisés à générer ou manipuler des entêtes SRH.<br /> <br /> ----------------------<br /> <br /> Cette extension permet d'imposer à un paquet une route différente de celle offerte par les politiques de routage présentes sur le réseau (cf. Figure 4). Pour l'instant, seul le routage par la source (&lt;tt&gt;type&lt;/tt&gt; = 0), similaire à l'option ''Loose Source Routing'' d'IPv4, est défini pour IPv6. La mobilité IPv6 a également introduit une autre extension de routage (&lt;tt&gt;type&lt;/tt&gt; = 2, optimisation dans le cas du mobile dans un réseau étranger).<br /> &lt;center&gt;<br /> [[image:2015_10_14_IPv6_extension_routage_v00.jpg|thumb|center|400px|Figure 4 : Routage par la source.]]<br /> &lt;/center&gt;<br /> Dans IPv4, le routage peut être strict (le routeur suivant, présent dans la liste, doit être un voisin directement accessible) ou libéral ''loose'' (un routeur peut utiliser les tables de routage pour joindre le routeur suivant, servant de relais). Dans IPv6, seul le routage libéral est autorisé. En effet, le routage strict était initialement mis en place surtout pour des raisons de sécurité. La source devait être absolument sûre du chemin pris par les paquets. Cette utilisation a maintenant disparu du réseau. <br /> <br /> Le principe du routage par la source, ou ''Source Routing'', dans IPv4, qui vient d’être rappelé, est le même pour IPv6. L'émetteur met, dans le champ &lt;tt&gt;destination&lt;/tt&gt; du paquet IPv6, l'adresse du premier routeur servant de relais. L'extension contient la suite de la liste des autres routeurs relais et le destinataire. Quand un routeur reçoit un paquet qui lui est adressé, comportant une extension de routage par la source, il permute son adresse avec l'adresse du prochain routeur et réémet le paquet vers cette adresse suivante.<br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_IPv6_extension_routage_v02.jpg|thumb|center|400px|Figure 5 : Extension de routage par la source.]]<br /> &lt;/center&gt;<br /> <br /> La figure 5 donne le format de l'extension de routage par la source : <br /> * Le champ de longueur &lt;tt&gt;Hdr Ext Len&lt;/tt&gt; de l'en-tête indique le nombre de mots de 64 bits qui composent l'extension. Pour l'extension de &lt;tt&gt;type&lt;/tt&gt; 0, cela correspond au nombre d'adresses présentes dans la liste, multiplié par 2. <br /> * Le champ &lt;tt&gt;Routing Type&lt;/tt&gt; indique la nature du routage. Pour l'instant, seul le routage par la source, de &lt;tt&gt;type&lt;/tt&gt; 0 est spécifié. La suite de l'en-tête correspond à ce &lt;tt&gt;type&lt;/tt&gt;. <br /> * Le champs &lt;tt&gt;Segment Left&lt;/tt&gt; est décrémenté après la traversée d'un routeur. Il indique le nombre d'équipements qui doivent encore être traversés. Il permet de trouver l'adresse qui devra être substituée. <br /> * Les 32 bits suivants sont inutilisés pour préserver l'alignement. <br /> * La liste, comprenant les routeurs à traverser et le destinataire, est fournie. Ces adresses ne peuvent pas être de type multicast.<br /> <br /> À noter : il n'y a pas de champ &lt;tt&gt;NH&lt;/tt&gt; dans TCP.<br /> <br /> Dans la figure 6, nous pouvons suivre l’évolution des changements des champs pendant la traversée du réseau du paquet IPv6 :<br /> * Noter l’évolution du champ &lt;tt&gt;Segment Left&lt;/tt&gt; qui pointe vers l’adresse du prochain routeur spécifié apte à traiter l’extension RH0.<br /> * Chaque routeur spécifié successif remplace l’adresse destination du datagramme avec l’adresse pointée par le champ &lt;tt&gt;Segment Left&lt;/tt&gt;. Une fois que le pointeur est décrémenté à 0, plus aucun changement ne sera effectué.<br /> * Les routeurs non spécifiés relaient les paquets de manière transparente.<br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_IPv6_extension_RH0_04.jpg|thumb|center|665px|Figure 6 : Extension de routage.]]<br /> &lt;/center&gt;<br /> <br /> == Conclusion ==<br /> 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 communications 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.<br /> <br /> 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 pris en compte dans le traitement des paquets, notamment le filtrage sur les valeurs du champ ''Next Header'' de l'en-tête IPv6.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin==<br /> Vous pouvez approfondir vos connaissances en consultant les documents de ce paragraphe.<br /> RFC et leur analyse par S. Bortzmeyer :<br /> * RFC 1981 : Path MTU Discovery for IP version 6<br /> * RFC 2460 : Internet Protocol, Version 6 (IPv6) Specification [http://www.bortzmeyer.org/2460.html Analyse]<br /> * RFC 4302 : IP Authentication Header<br /> * RFC 4303 : IP Encapsulating Security Payload (ESP)<br /> * RFC 5095 : Deprecation of Type 0 Routing Headers in IPv6 Specification [http://www.bortzmeyer.org/5095.html Analyse]<br /> * RFC 7045 : Transmission and Processing of IPv6 Extension Headers [http://www.bortzmeyer.org/7045.html Analyse]<br /> * RFC 7872 : Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World [http://www.bortzmeyer.org/7872.html Analyse]<br /> * [http://livre.g6.asso.fr/index.php/S%C3%A9curit%C3%A9 Chapitre Sécurité du livre &quot;IPv6, Théorie et Pratique&quot;]</div> Ptournoux2 http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act24-s6&diff=14922 MOOC:Compagnon Act24-s6 2017-04-24T10:48:30Z <p>Ptournoux2: /* Segment Routing Header (SRH) */</p> <hr /> <div>__NOTOC__ <br /> =Activité 24 : Le mécanisme d’extension de l'en-tête IPv6=<br /> <br /> == Introduction ==<br /> <br /> 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 :<br /> * soit par le destinataire du paquet IPv6,<br /> * soit par les routeurs intermédiaires en charge de l’acheminement du paquet IPv6.<br /> <br /> De nombreuses extensions ont été définies, afin d'assurer des fonctions comme : <br /> * le routage par la source,<br /> * la gestion de la fragmentation,<br /> * la confidentialité des communications (mécanisme ''ipsec''),<br /> * etc. <br /> <br /> 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.<br /> <br /> == Principe des extensions IPv6==<br /> <br /> 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).<br /> Une extension a une longueur multiple de 8 octets (64 bits). Elle commence par un champ &lt;tt&gt;Next header&lt;/tt&gt; qui définit sur 1 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.<br /> <br /> 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.<br /> <br /> '''''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.''<br /> <br /> Une présentation illustrée des extensionsIPv6 peut être consultée sur le site de Cisco&lt;ref&gt;Cisco (2006) White paper.[http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html IPv6 Extension Headers Review and Considerations]&lt;/ref&gt;.<br /> <br /> == Le champ ''Next Header'' ==<br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_ipv6_header_next-header_v02.jpg|thumb|right|300px|Figure 1 : Localisation du champ &lt;tt&gt;Next Header&lt;/tt&gt; dans l'en-tête IPv6.]]<br /> &lt;/center&gt;<br /> Le champ &lt;tt&gt;Next Header&lt;/tt&gt; 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 :<br /> &lt;center&gt;{{MOOC_Valeurs_du_champ_en-tête_suivant}}<br /> &lt;/center&gt;<br /> <br /> == Intégration des extensions d’en-tête dans le paquet IPv6==<br /> 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: <br /> * extensions impliquant tous les routeurs intermédiaires : ''Hop-by-Hop'' ;<br /> * extensions impliquant seulement certains routeurs désignés : ''Routing'' ;<br /> * extension impliquant le destinataire : ''Authentication'', ''Encapsulating Security Payload'', Fragmentation, Destination.<br /> <br /> <br /> 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 &lt;tt&gt;en-tête suivant&lt;/tt&gt; et un champ &lt;tt&gt;longueur&lt;/tt&gt;. Le premier paquet ne contient pas d'extension ; le champ &lt;tt&gt;en-tête suivant&lt;/tt&gt; pointe sur ICMPv6. Le second paquet ne contient pas d'extension ; le champ &lt;tt&gt;en-tête suivant&lt;/tt&gt; 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. <br /> * 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.<br /> * 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. <br /> * Les extensions peuvent être vues comme un protocole 3.5 (entre la couche 3 et la couche 4). En effet, à part l'extension de &quot;proche en proche&quot;, 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 &lt;tt&gt;adresse de destination&lt;/tt&gt; du paquet IPv6). <br /> <br /> &lt;center&gt;<br /> [[image:2015_10_10_extensions_IPv6_v01.jpg|thumb|center|600px|Figure 2 : Enchaînement d'extensions.]]<br /> &lt;/center&gt;<br /> <br /> == Quelques exemples ==<br /> <br /> === Fragmentation ===<br /> La fragmentation, telle qu'elle est pratiquée dans IPv4, n'est pas très performante. Initialement, elle servait à rendre transparente les limitations physiques des supports de transmission. Dans IPv4, quand un routeur ne peut pas transmettre un paquet à cause de sa trop grande taille, et si le bit DF ''don't fragment'' est à 0, il découpe l'information à transmettre en fragments. Or, le réseau IP étant un réseau à datagrammes, il n'y a pas de possibilité de contrôler les fragments. Deux fragments successifs peuvent prendre deux chemins différents et, par conséquent, seul le destinataire peut effectuer le ré-assemblage. En conséquence, après la traversée d'un lien impliquant une fragmentation, le reste du réseau ne voit passer que des paquets de taille réduite. <br /> <br /> 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 1981 : Mécanisme de découverte du PMTU). En pratique, une taille de paquets de 1 500 octets est presque universelle.<br /> <br /> Il existe pourtant des cas où la fragmentation est nécessaire. Ainsi, une application telle que NFS sur UDP suppose que la fragmentation existe et produit des messages de taille quelconque. Comme on ne veut pas modifier ces applications, la couche réseau d'IPv6 doit aussi être capable de gérer la fragmentation. Pour réduire le travail des routeurs intermédiaires, la fragmentation se fera au niveau de la source et le ré-assemblage par le destinataire. Les informations utiles pour ces mécanismes (identification du paquet fragmenté, place du fragment) sont transportées dans une extension de fragmentation, représentée dans la figure 3. <br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_PMTU_5_v01.jpg|thumb|center|600px|Figure 3 : Format de l'extension de fragmentation.]]<br /> &lt;/center&gt;<br /> <br /> * Le champ longueur de l'extension est remplacé par un champ réservé, positionné pour l'instant à 0. Un champ de longueur est, car l'extension tient sur un seul mot de 64 bits et le premier mot n'est pas compté dans le calcul de longueur des extensions.<br /> * Le &lt;tt&gt;fragment offset&lt;/tt&gt; indique, lors du ré-assemblage, la position à laquelle les données du fragment doivent s'insérer. Ceci permet de résoudre les problèmes dus au déséquencement éventuel des datagrammes. Ce champ étant sur 13 bits, la taille des fragments, excepté le dernier, doit être multiple de 8 octets (alignement sur frontière de mots de 64 bits),<br /> * Le bit &lt;tt&gt;M&lt;/tt&gt; (More data) est à 1 sur les fragments intermédiaires et à 0 sur le fragment final,<br /> * Le champ &lt;tt&gt;identification&lt;/tt&gt; permet de repérer les fragments appartenant à un même paquet initial pour une source et une destination données.<br /> <br /> Le bit DF (Don't Fragment), de l'en-tête IPv4 n'est plus nécessaire. Si un paquet est trop grand, il y aura rejet par le routeur et émission d'un message ICMP.<br /> <br /> Dans IPv6, 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 les autres extensions et l'en-tête de niveau 4 ne seront présents que dans le premier fragment.<br /> <br /> Le mécanisme de gestion de la taille d'un paquet IPv6, selon les différents cas possibles, est approfondi dans l'activité suivante.<br /> <br /> === Extensions d'authentification (AH) et de confidentialité (ESP) ===<br /> <br /> 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.<br /> <br /> 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. C'est-à-dire, si un code d'authentification de message &lt;ref&gt;Code d'authentification de message, [https://fr.wikipedia.org/wiki/Code_d%27authentification_de_message Article Wikipedia]&lt;/ref&gt; est utilisé, il lui suffit 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.<br /> <br /> 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.<br /> <br /> 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 algorithme(s) de chiffrement, la ou les clé(s), et un indice de paramètres de sécurité.<br /> <br /> === Segment Routing Header (SRH) ===<br /> <br /> Cette extension est une des briques qui permet la mise en oeuvre de l'ingénierie de traffic et de la qualité de sevice 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 necessiter que le délai de bout en bout reste inférieur à 100ms, que le débit disponible soit au minimum de 2mbit/s et que le taux de perte reste inférieur à 1%. La solution habituellement mise en oeuvre pour le respect de ces métriques de qualité de service est RSVP-TE&lt;ref&gt;Packet Pushers, Novembre 2016 .[http://packetpushers.net/rsvp-te-protocol-deep-dive/ Deep dive in the RSVP-TE protocol]&lt;/ref&gt;. RSVP est un protocol de reservation de ressource sur les routeurs du chemin entre une source et une destination. La composante d'ingenerie de traffic permet notamment de choisir explicitement le chemin qui sera suivit par le paquet. Lorsqu'une appication aura besoin de reserver des ressources, un circuit MPLS sera établi et le protocole RSVP reservera les ressources sur l'ensemble des routeurs qui composent le chemin. La figure X résume ce comportement, le noeud A est la source du flot de vidéo conférence destiné à B, elle demande l'installation d'un chemin via MPLS. Le controleur determine 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 doivent accepter la requête.<br /> <br /> <br /> <br /> &lt;center&gt;<br /> [[image:Moocipv6-act24-SRH-rsvp2.png|thumb|center|400px|Figure 4 : Exemple d'utilisation de RSVP-TE pour assurer la qualité de service.]]<br /> &lt;/center&gt;<br /> <br /> <br /> 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. A 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 couteux en temps, en états, et en communication. Pour finir, si un des équipements 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 [[http://www.segment-routing.net/tutorials/2017-03-06-segment-routing-traffic-engineering-srte/]].<br /> <br /> Le concept de segment routing a été proposé pour palier à ces désavantages. Il permet de réduire l'intelligence des équipements du réseau. Un controleur choisi le chemin qui respecte les besoins de qualité de service du noeud. Le chemin à suivre ainsi que le traitement à associer aux paquets sont ensuite explicitement listés dans leurs entê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 à empreinter ou encore un service fournit par le routeur sur lequel transite le paquet. La séquence de segments que doit suivre le paquet peut être implémenté via une liste de label MPLS ou dans le cas d'en réseau IPv6 via l'option Segment Routing de l'entête [https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06]. Contrairement à MPLS, le segment routing avec IPv6 ne requière pas que tous les équipements traversés par le paquet soient compatibles avec cette option. Cela permet un déploiement progressif et de traverser plusieurs types de réseaux. Notons qu'il n'est pas necessaire d'inscrire l'integralité du chemin dans la liste. Les règles routage classique (IGP) s'appliquent pour acheminer le paquets entre les noeuds explicitement listés dans l'entête. Dans le cas de la figure 2, pour suivre le chemin G,H,I,K,N, il est seulement necessaire 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.a.d. B. Le paquet suit le plus court chemin entre I et B en l'occurence I,K,N. La taille de l'entête est donc limitée.<br /> <br /> <br /> <br /> &lt;center&gt;<br /> [[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.]]<br /> &lt;/center&gt;<br /> <br /> <br /> <br /> Le projet de RFC [https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06] prevoit qu'un segment soit représenté sur 128bit, c.a.d. autant qu'une adresse IPv6. Le nombre de segments inclus dans l'option SRH peut être déduit du champs Hdr Ext Len qui indique le nombre d'octets de l'option moins un. Le prochain segment à appliquer est indiqué par le champs Segments Left qui indique nombre de segments restant à appliquer au paquet. Le segment courant est inscrit dans le champs adresse de destination de l'entête IPv6. Lorsque le traitement associé à un segment est achevé, le prochain segment à traiter est copié dans le champs adresse de destination et le champs Segments Left est décrementé.<br /> <br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_IPv6_extension_routage_v02.jpg|thumb|center|400px|Figure 5 : Extension de routage par la source.]]<br /> &lt;/center&gt;<br /> <br /> L'option SRH est très proche de l'entête de routage défini dans la RFC2460 de IPv6. L'entête de routage devait notamment permettre le routage à la source qui conciste à lister les routeurs que devaient traverser le paquet au cours de son acheminement. Cette pratique a été dépréciée en 2007 par la RFC 5095 pour des raisons de sécurité. En effet cela permettait de generer de la congestion sur certains chemins, des attaques de déni de service, de contourner les règles de filtrages de certains parfeu ou encore d'atteindre des machines publiques accessibles (en DMZ) pour acceder à des machines qui ne sont pas directement accessibles. [A completer: http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf].<br /> <br /> Pour être accepté, l'option SRH devait donc garantir qu'elle ne serait pas vulnérable à ces attaques. Plusieurs cas d'utilisation sont décrits. Lorsque la SRH est générée au sein du réseau de l'opérateur (e.g. routeur de bordure) les attaques listées dans la RFC5095 sont innopérantes. Les routeurs de bordures doivent simplement filtrer les paquets venus de l'exterieur pour éviter de hôtes s'attribuent des privilèges ou provoque de la congestion sur certains lien. Lorsque les SRH sont générées en dehors du réseau de l'opérateur, la projet de RFC prévoit l'utilisation d'un mécanisme d'autentification de l'entête [RFC2104] (option HMAC). La clé de chiffrement de l'entête HMAC est distribuée au sein des noeuds autorisés à générer ou manipuler des entêtes SRH.<br /> <br /> <br /> <br /> ----------------------<br /> <br /> Cette extension permet d'imposer à un paquet une route différente de celle offerte par les politiques de routage présentes sur le réseau (cf. Figure 4). Pour l'instant, seul le routage par la source (&lt;tt&gt;type&lt;/tt&gt; = 0), similaire à l'option ''Loose Source Routing'' d'IPv4, est défini pour IPv6. La mobilité IPv6 a également introduit une autre extension de routage (&lt;tt&gt;type&lt;/tt&gt; = 2, optimisation dans le cas du mobile dans un réseau étranger).<br /> &lt;center&gt;<br /> [[image:2015_10_14_IPv6_extension_routage_v00.jpg|thumb|center|400px|Figure 4 : Routage par la source.]]<br /> &lt;/center&gt;<br /> Dans IPv4, le routage peut être strict (le routeur suivant, présent dans la liste, doit être un voisin directement accessible) ou libéral ''loose'' (un routeur peut utiliser les tables de routage pour joindre le routeur suivant, servant de relais). Dans IPv6, seul le routage libéral est autorisé. En effet, le routage strict était initialement mis en place surtout pour des raisons de sécurité. La source devait être absolument sûre du chemin pris par les paquets. Cette utilisation a maintenant disparu du réseau. <br /> <br /> Le principe du routage par la source, ou ''Source Routing'', dans IPv4, qui vient d’être rappelé, est le même pour IPv6. L'émetteur met, dans le champ &lt;tt&gt;destination&lt;/tt&gt; du paquet IPv6, l'adresse du premier routeur servant de relais. L'extension contient la suite de la liste des autres routeurs relais et le destinataire. Quand un routeur reçoit un paquet qui lui est adressé, comportant une extension de routage par la source, il permute son adresse avec l'adresse du prochain routeur et réémet le paquet vers cette adresse suivante.<br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_IPv6_extension_routage_v02.jpg|thumb|center|400px|Figure 5 : Extension de routage par la source.]]<br /> &lt;/center&gt;<br /> <br /> La figure 5 donne le format de l'extension de routage par la source : <br /> * Le champ de longueur &lt;tt&gt;Hdr Ext Len&lt;/tt&gt; de l'en-tête indique le nombre de mots de 64 bits qui composent l'extension. Pour l'extension de &lt;tt&gt;type&lt;/tt&gt; 0, cela correspond au nombre d'adresses présentes dans la liste, multiplié par 2. <br /> * Le champ &lt;tt&gt;Routing Type&lt;/tt&gt; indique la nature du routage. Pour l'instant, seul le routage par la source, de &lt;tt&gt;type&lt;/tt&gt; 0 est spécifié. La suite de l'en-tête correspond à ce &lt;tt&gt;type&lt;/tt&gt;. <br /> * Le champs &lt;tt&gt;Segment Left&lt;/tt&gt; est décrémenté après la traversée d'un routeur. Il indique le nombre d'équipements qui doivent encore être traversés. Il permet de trouver l'adresse qui devra être substituée. <br /> * Les 32 bits suivants sont inutilisés pour préserver l'alignement. <br /> * La liste, comprenant les routeurs à traverser et le destinataire, est fournie. Ces adresses ne peuvent pas être de type multicast.<br /> <br /> À noter : il n'y a pas de champ &lt;tt&gt;NH&lt;/tt&gt; dans TCP.<br /> <br /> Dans la figure 6, nous pouvons suivre l’évolution des changements des champs pendant la traversée du réseau du paquet IPv6 :<br /> * Noter l’évolution du champ &lt;tt&gt;Segment Left&lt;/tt&gt; qui pointe vers l’adresse du prochain routeur spécifié apte à traiter l’extension RH0.<br /> * Chaque routeur spécifié successif remplace l’adresse destination du datagramme avec l’adresse pointée par le champ &lt;tt&gt;Segment Left&lt;/tt&gt;. Une fois que le pointeur est décrémenté à 0, plus aucun changement ne sera effectué.<br /> * Les routeurs non spécifiés relaient les paquets de manière transparente.<br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_IPv6_extension_RH0_04.jpg|thumb|center|665px|Figure 6 : Extension de routage.]]<br /> &lt;/center&gt;<br /> <br /> == Conclusion ==<br /> 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 communications 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.<br /> <br /> 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 pris en compte dans le traitement des paquets, notamment le filtrage sur les valeurs du champ ''Next Header'' de l'en-tête IPv6.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin==<br /> Vous pouvez approfondir vos connaissances en consultant les documents de ce paragraphe.<br /> RFC et leur analyse par S. Bortzmeyer :<br /> * RFC 1981 : Path MTU Discovery for IP version 6<br /> * RFC 2460 : Internet Protocol, Version 6 (IPv6) Specification [http://www.bortzmeyer.org/2460.html Analyse]<br /> * RFC 4302 : IP Authentication Header<br /> * RFC 4303 : IP Encapsulating Security Payload (ESP)<br /> * RFC 5095 : Deprecation of Type 0 Routing Headers in IPv6 Specification [http://www.bortzmeyer.org/5095.html Analyse]<br /> * RFC 7045 : Transmission and Processing of IPv6 Extension Headers [http://www.bortzmeyer.org/7045.html Analyse]<br /> * RFC 7872 : Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World [http://www.bortzmeyer.org/7872.html Analyse]<br /> * [http://livre.g6.asso.fr/index.php/S%C3%A9curit%C3%A9 Chapitre Sécurité du livre &quot;IPv6, Théorie et Pratique&quot;]</div> Ptournoux2 http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act24-s6&diff=14921 MOOC:Compagnon Act24-s6 2017-04-24T10:39:16Z <p>Ptournoux2: /* Segment Routing Header (SRH) */</p> <hr /> <div>__NOTOC__ <br /> =Activité 24 : Le mécanisme d’extension de l'en-tête IPv6=<br /> <br /> == Introduction ==<br /> <br /> 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 :<br /> * soit par le destinataire du paquet IPv6,<br /> * soit par les routeurs intermédiaires en charge de l’acheminement du paquet IPv6.<br /> <br /> De nombreuses extensions ont été définies, afin d'assurer des fonctions comme : <br /> * le routage par la source,<br /> * la gestion de la fragmentation,<br /> * la confidentialité des communications (mécanisme ''ipsec''),<br /> * etc. <br /> <br /> 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.<br /> <br /> == Principe des extensions IPv6==<br /> <br /> 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).<br /> Une extension a une longueur multiple de 8 octets (64 bits). Elle commence par un champ &lt;tt&gt;Next header&lt;/tt&gt; qui définit sur 1 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.<br /> <br /> 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.<br /> <br /> '''''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.''<br /> <br /> Une présentation illustrée des extensionsIPv6 peut être consultée sur le site de Cisco&lt;ref&gt;Cisco (2006) White paper.[http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html IPv6 Extension Headers Review and Considerations]&lt;/ref&gt;.<br /> <br /> == Le champ ''Next Header'' ==<br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_ipv6_header_next-header_v02.jpg|thumb|right|300px|Figure 1 : Localisation du champ &lt;tt&gt;Next Header&lt;/tt&gt; dans l'en-tête IPv6.]]<br /> &lt;/center&gt;<br /> Le champ &lt;tt&gt;Next Header&lt;/tt&gt; 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 :<br /> &lt;center&gt;{{MOOC_Valeurs_du_champ_en-tête_suivant}}<br /> &lt;/center&gt;<br /> <br /> == Intégration des extensions d’en-tête dans le paquet IPv6==<br /> 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: <br /> * extensions impliquant tous les routeurs intermédiaires : ''Hop-by-Hop'' ;<br /> * extensions impliquant seulement certains routeurs désignés : ''Routing'' ;<br /> * extension impliquant le destinataire : ''Authentication'', ''Encapsulating Security Payload'', Fragmentation, Destination.<br /> <br /> <br /> 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 &lt;tt&gt;en-tête suivant&lt;/tt&gt; et un champ &lt;tt&gt;longueur&lt;/tt&gt;. Le premier paquet ne contient pas d'extension ; le champ &lt;tt&gt;en-tête suivant&lt;/tt&gt; pointe sur ICMPv6. Le second paquet ne contient pas d'extension ; le champ &lt;tt&gt;en-tête suivant&lt;/tt&gt; 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. <br /> * 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.<br /> * 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. <br /> * Les extensions peuvent être vues comme un protocole 3.5 (entre la couche 3 et la couche 4). En effet, à part l'extension de &quot;proche en proche&quot;, 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 &lt;tt&gt;adresse de destination&lt;/tt&gt; du paquet IPv6). <br /> <br /> &lt;center&gt;<br /> [[image:2015_10_10_extensions_IPv6_v01.jpg|thumb|center|600px|Figure 2 : Enchaînement d'extensions.]]<br /> &lt;/center&gt;<br /> <br /> == Quelques exemples ==<br /> <br /> === Fragmentation ===<br /> La fragmentation, telle qu'elle est pratiquée dans IPv4, n'est pas très performante. Initialement, elle servait à rendre transparente les limitations physiques des supports de transmission. Dans IPv4, quand un routeur ne peut pas transmettre un paquet à cause de sa trop grande taille, et si le bit DF ''don't fragment'' est à 0, il découpe l'information à transmettre en fragments. Or, le réseau IP étant un réseau à datagrammes, il n'y a pas de possibilité de contrôler les fragments. Deux fragments successifs peuvent prendre deux chemins différents et, par conséquent, seul le destinataire peut effectuer le ré-assemblage. En conséquence, après la traversée d'un lien impliquant une fragmentation, le reste du réseau ne voit passer que des paquets de taille réduite. <br /> <br /> 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 1981 : Mécanisme de découverte du PMTU). En pratique, une taille de paquets de 1 500 octets est presque universelle.<br /> <br /> Il existe pourtant des cas où la fragmentation est nécessaire. Ainsi, une application telle que NFS sur UDP suppose que la fragmentation existe et produit des messages de taille quelconque. Comme on ne veut pas modifier ces applications, la couche réseau d'IPv6 doit aussi être capable de gérer la fragmentation. Pour réduire le travail des routeurs intermédiaires, la fragmentation se fera au niveau de la source et le ré-assemblage par le destinataire. Les informations utiles pour ces mécanismes (identification du paquet fragmenté, place du fragment) sont transportées dans une extension de fragmentation, représentée dans la figure 3. <br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_PMTU_5_v01.jpg|thumb|center|600px|Figure 3 : Format de l'extension de fragmentation.]]<br /> &lt;/center&gt;<br /> <br /> * Le champ longueur de l'extension est remplacé par un champ réservé, positionné pour l'instant à 0. Un champ de longueur est, car l'extension tient sur un seul mot de 64 bits et le premier mot n'est pas compté dans le calcul de longueur des extensions.<br /> * Le &lt;tt&gt;fragment offset&lt;/tt&gt; indique, lors du ré-assemblage, la position à laquelle les données du fragment doivent s'insérer. Ceci permet de résoudre les problèmes dus au déséquencement éventuel des datagrammes. Ce champ étant sur 13 bits, la taille des fragments, excepté le dernier, doit être multiple de 8 octets (alignement sur frontière de mots de 64 bits),<br /> * Le bit &lt;tt&gt;M&lt;/tt&gt; (More data) est à 1 sur les fragments intermédiaires et à 0 sur le fragment final,<br /> * Le champ &lt;tt&gt;identification&lt;/tt&gt; permet de repérer les fragments appartenant à un même paquet initial pour une source et une destination données.<br /> <br /> Le bit DF (Don't Fragment), de l'en-tête IPv4 n'est plus nécessaire. Si un paquet est trop grand, il y aura rejet par le routeur et émission d'un message ICMP.<br /> <br /> Dans IPv6, 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 les autres extensions et l'en-tête de niveau 4 ne seront présents que dans le premier fragment.<br /> <br /> Le mécanisme de gestion de la taille d'un paquet IPv6, selon les différents cas possibles, est approfondi dans l'activité suivante.<br /> <br /> === Extensions d'authentification (AH) et de confidentialité (ESP) ===<br /> <br /> 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.<br /> <br /> 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. C'est-à-dire, si un code d'authentification de message &lt;ref&gt;Code d'authentification de message, [https://fr.wikipedia.org/wiki/Code_d%27authentification_de_message Article Wikipedia]&lt;/ref&gt; est utilisé, il lui suffit 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.<br /> <br /> 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.<br /> <br /> 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 algorithme(s) de chiffrement, la ou les clé(s), et un indice de paramètres de sécurité.<br /> <br /> === Segment Routing Header (SRH) ===<br /> <br /> Cette extension est une des briques qui permet la mise en oeuvre de l'ingénierie de traffic et de la qualité de sevice 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 necessiter que le délai de bout en bout reste inférieur à 100ms, que le débit disponible soit au minimum de 2mbit/s et que le taux de perte reste inférieur à 1%. La solution habituellement mise en oeuvre pour le respect de ces métriques de qualité de service est RSVP-TE [Pujolle Les Réseaux 2014]. RSVP est un protocol de reservation de ressource sur les routeurs du chemin entre une source et une destination. La composante d'ingenerie de traffic permet notamment de choisir explicitement le chemin qui sera suivit par le paquet. Lorsqu'une appication aura besoin de reserver des ressources, un circuit MPLS sera établi et le protocole RSVP reservera les ressources sur l'ensemble des routeurs qui composent le chemin. La figure X résume ce comportement, le noeud A est la source du flot de vidéo conférence destiné à B, elle demande l'installation d'un chemin via MPLS. Le controleur determine 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 doivent accepter la requête.<br /> <br /> <br /> <br /> &lt;center&gt;<br /> [[image:Moocipv6-act24-SRH-rsvp2.png|thumb|center|400px|Figure 4 : Exemple d'utilisation de RSVP-TE pour assurer la qualité de service.]]<br /> &lt;/center&gt;<br /> <br /> <br /> 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. A 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 couteux en temps, en états, et en communication. Pour finir, si un des équipements 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 [[http://www.segment-routing.net/tutorials/2017-03-06-segment-routing-traffic-engineering-srte/]].<br /> <br /> Le concept de segment routing a été proposé pour palier à ces désavantages. Il permet de réduire l'intelligence des équipements du réseau. Un controleur choisi le chemin qui respecte les besoins de qualité de service du noeud. Le chemin à suivre ainsi que le traitement à associer aux paquets sont ensuite explicitement listés dans leurs entê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 à empreinter ou encore un service fournit par le routeur sur lequel transite le paquet. La séquence de segments que doit suivre le paquet peut être implémenté via une liste de label MPLS ou dans le cas d'en réseau IPv6 via l'option Segment Routing de l'entête [https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06]. Contrairement à MPLS, le segment routing avec IPv6 ne requière pas que tous les équipements traversés par le paquet soient compatibles avec cette option. Cela permet un déploiement progressif et de traverser plusieurs types de réseaux. Notons qu'il n'est pas necessaire d'inscrire l'integralité du chemin dans la liste. Les règles routage classique (IGP) s'appliquent pour acheminer le paquets entre les noeuds explicitement listés dans l'entête. Dans le cas de la figure 2, pour suivre le chemin G,H,I,K,N, il est seulement necessaire 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.a.d. B. Le paquet suit le plus court chemin entre I et B en l'occurence I,K,N. La taille de l'entête est donc limitée.<br /> <br /> <br /> <br /> &lt;center&gt;<br /> [[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.]]<br /> &lt;/center&gt;<br /> <br /> <br /> <br /> Le projet de RFC [https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06] prevoit qu'un segment soit représenté sur 128bit, c.a.d. autant qu'une adresse IPv6. Le nombre de segments inclus dans l'option SRH peut être déduit du champs Hdr Ext Len qui indique le nombre d'octets de l'option moins un. Le prochain segment à appliquer est indiqué par le champs Segments Left qui indique nombre de segments restant à appliquer au paquet. Le segment courant est inscrit dans le champs adresse de destination de l'entête IPv6. Lorsque le traitement associé à un segment est achevé, le prochain segment à traiter est copié dans le champs adresse de destination et le champs Segments Left est décrementé.<br /> <br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_IPv6_extension_routage_v02.jpg|thumb|center|400px|Figure 5 : Extension de routage par la source.]]<br /> &lt;/center&gt;<br /> <br /> L'option SRH est très proche de l'entête de routage défini dans la RFC2460 de IPv6. L'entête de routage devait notamment permettre le routage à la source qui conciste à lister les routeurs que devaient traverser le paquet au cours de son acheminement. Cette pratique a été dépréciée en 2007 par la RFC 5095 pour des raisons de sécurité. En effet cela permettait de generer de la congestion sur certains chemins, des attaques de déni de service, de contourner les règles de filtrages de certains parfeu ou encore d'atteindre des machines publiques accessibles (en DMZ) pour acceder à des machines qui ne sont pas directement accessibles. [A completer: http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf].<br /> <br /> Pour être accepté, l'option SRH devait donc garantir qu'elle ne serait pas vulnérable à ces attaques. Plusieurs cas d'utilisation sont décrits. Lorsque la SRH est générée au sein du réseau de l'opérateur (e.g. routeur de bordure) les attaques listées dans la RFC5095 sont innopérantes. Les routeurs de bordures doivent simplement filtrer les paquets venus de l'exterieur pour éviter de hôtes s'attribuent des privilèges ou provoque de la congestion sur certains lien. Lorsque les SRH sont générées en dehors du réseau de l'opérateur, la projet de RFC prévoit l'utilisation d'un mécanisme d'autentification de l'entête [RFC2104] (option HMAC). La clé de chiffrement de l'entête HMAC est distribuée au sein des noeuds autorisés à générer ou manipuler des entêtes SRH.<br /> <br /> <br /> <br /> ----------------------<br /> <br /> Cette extension permet d'imposer à un paquet une route différente de celle offerte par les politiques de routage présentes sur le réseau (cf. Figure 4). Pour l'instant, seul le routage par la source (&lt;tt&gt;type&lt;/tt&gt; = 0), similaire à l'option ''Loose Source Routing'' d'IPv4, est défini pour IPv6. La mobilité IPv6 a également introduit une autre extension de routage (&lt;tt&gt;type&lt;/tt&gt; = 2, optimisation dans le cas du mobile dans un réseau étranger).<br /> &lt;center&gt;<br /> [[image:2015_10_14_IPv6_extension_routage_v00.jpg|thumb|center|400px|Figure 4 : Routage par la source.]]<br /> &lt;/center&gt;<br /> Dans IPv4, le routage peut être strict (le routeur suivant, présent dans la liste, doit être un voisin directement accessible) ou libéral ''loose'' (un routeur peut utiliser les tables de routage pour joindre le routeur suivant, servant de relais). Dans IPv6, seul le routage libéral est autorisé. En effet, le routage strict était initialement mis en place surtout pour des raisons de sécurité. La source devait être absolument sûre du chemin pris par les paquets. Cette utilisation a maintenant disparu du réseau. <br /> <br /> Le principe du routage par la source, ou ''Source Routing'', dans IPv4, qui vient d’être rappelé, est le même pour IPv6. L'émetteur met, dans le champ &lt;tt&gt;destination&lt;/tt&gt; du paquet IPv6, l'adresse du premier routeur servant de relais. L'extension contient la suite de la liste des autres routeurs relais et le destinataire. Quand un routeur reçoit un paquet qui lui est adressé, comportant une extension de routage par la source, il permute son adresse avec l'adresse du prochain routeur et réémet le paquet vers cette adresse suivante.<br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_IPv6_extension_routage_v02.jpg|thumb|center|400px|Figure 5 : Extension de routage par la source.]]<br /> &lt;/center&gt;<br /> <br /> La figure 5 donne le format de l'extension de routage par la source : <br /> * Le champ de longueur &lt;tt&gt;Hdr Ext Len&lt;/tt&gt; de l'en-tête indique le nombre de mots de 64 bits qui composent l'extension. Pour l'extension de &lt;tt&gt;type&lt;/tt&gt; 0, cela correspond au nombre d'adresses présentes dans la liste, multiplié par 2. <br /> * Le champ &lt;tt&gt;Routing Type&lt;/tt&gt; indique la nature du routage. Pour l'instant, seul le routage par la source, de &lt;tt&gt;type&lt;/tt&gt; 0 est spécifié. La suite de l'en-tête correspond à ce &lt;tt&gt;type&lt;/tt&gt;. <br /> * Le champs &lt;tt&gt;Segment Left&lt;/tt&gt; est décrémenté après la traversée d'un routeur. Il indique le nombre d'équipements qui doivent encore être traversés. Il permet de trouver l'adresse qui devra être substituée. <br /> * Les 32 bits suivants sont inutilisés pour préserver l'alignement. <br /> * La liste, comprenant les routeurs à traverser et le destinataire, est fournie. Ces adresses ne peuvent pas être de type multicast.<br /> <br /> À noter : il n'y a pas de champ &lt;tt&gt;NH&lt;/tt&gt; dans TCP.<br /> <br /> Dans la figure 6, nous pouvons suivre l’évolution des changements des champs pendant la traversée du réseau du paquet IPv6 :<br /> * Noter l’évolution du champ &lt;tt&gt;Segment Left&lt;/tt&gt; qui pointe vers l’adresse du prochain routeur spécifié apte à traiter l’extension RH0.<br /> * Chaque routeur spécifié successif remplace l’adresse destination du datagramme avec l’adresse pointée par le champ &lt;tt&gt;Segment Left&lt;/tt&gt;. Une fois que le pointeur est décrémenté à 0, plus aucun changement ne sera effectué.<br /> * Les routeurs non spécifiés relaient les paquets de manière transparente.<br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_IPv6_extension_RH0_04.jpg|thumb|center|665px|Figure 6 : Extension de routage.]]<br /> &lt;/center&gt;<br /> <br /> == Conclusion ==<br /> 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 communications 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.<br /> <br /> 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 pris en compte dans le traitement des paquets, notamment le filtrage sur les valeurs du champ ''Next Header'' de l'en-tête IPv6.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin==<br /> Vous pouvez approfondir vos connaissances en consultant les documents de ce paragraphe.<br /> RFC et leur analyse par S. Bortzmeyer :<br /> * RFC 1981 : Path MTU Discovery for IP version 6<br /> * RFC 2460 : Internet Protocol, Version 6 (IPv6) Specification [http://www.bortzmeyer.org/2460.html Analyse]<br /> * RFC 4302 : IP Authentication Header<br /> * RFC 4303 : IP Encapsulating Security Payload (ESP)<br /> * RFC 5095 : Deprecation of Type 0 Routing Headers in IPv6 Specification [http://www.bortzmeyer.org/5095.html Analyse]<br /> * RFC 7045 : Transmission and Processing of IPv6 Extension Headers [http://www.bortzmeyer.org/7045.html Analyse]<br /> * RFC 7872 : Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World [http://www.bortzmeyer.org/7872.html Analyse]<br /> * [http://livre.g6.asso.fr/index.php/S%C3%A9curit%C3%A9 Chapitre Sécurité du livre &quot;IPv6, Théorie et Pratique&quot;]</div> Ptournoux2 http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act24-s6&diff=14920 MOOC:Compagnon Act24-s6 2017-04-24T10:37:03Z <p>Ptournoux2: /* Segment Routing Header (SRH) */</p> <hr /> <div>__NOTOC__ <br /> =Activité 24 : Le mécanisme d’extension de l'en-tête IPv6=<br /> <br /> == Introduction ==<br /> <br /> 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 :<br /> * soit par le destinataire du paquet IPv6,<br /> * soit par les routeurs intermédiaires en charge de l’acheminement du paquet IPv6.<br /> <br /> De nombreuses extensions ont été définies, afin d'assurer des fonctions comme : <br /> * le routage par la source,<br /> * la gestion de la fragmentation,<br /> * la confidentialité des communications (mécanisme ''ipsec''),<br /> * etc. <br /> <br /> 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.<br /> <br /> == Principe des extensions IPv6==<br /> <br /> 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).<br /> Une extension a une longueur multiple de 8 octets (64 bits). Elle commence par un champ &lt;tt&gt;Next header&lt;/tt&gt; qui définit sur 1 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.<br /> <br /> 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.<br /> <br /> '''''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.''<br /> <br /> Une présentation illustrée des extensionsIPv6 peut être consultée sur le site de Cisco&lt;ref&gt;Cisco (2006) White paper.[http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html IPv6 Extension Headers Review and Considerations]&lt;/ref&gt;.<br /> <br /> == Le champ ''Next Header'' ==<br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_ipv6_header_next-header_v02.jpg|thumb|right|300px|Figure 1 : Localisation du champ &lt;tt&gt;Next Header&lt;/tt&gt; dans l'en-tête IPv6.]]<br /> &lt;/center&gt;<br /> Le champ &lt;tt&gt;Next Header&lt;/tt&gt; 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 :<br /> &lt;center&gt;{{MOOC_Valeurs_du_champ_en-tête_suivant}}<br /> &lt;/center&gt;<br /> <br /> == Intégration des extensions d’en-tête dans le paquet IPv6==<br /> 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: <br /> * extensions impliquant tous les routeurs intermédiaires : ''Hop-by-Hop'' ;<br /> * extensions impliquant seulement certains routeurs désignés : ''Routing'' ;<br /> * extension impliquant le destinataire : ''Authentication'', ''Encapsulating Security Payload'', Fragmentation, Destination.<br /> <br /> <br /> 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 &lt;tt&gt;en-tête suivant&lt;/tt&gt; et un champ &lt;tt&gt;longueur&lt;/tt&gt;. Le premier paquet ne contient pas d'extension ; le champ &lt;tt&gt;en-tête suivant&lt;/tt&gt; pointe sur ICMPv6. Le second paquet ne contient pas d'extension ; le champ &lt;tt&gt;en-tête suivant&lt;/tt&gt; 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. <br /> * 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.<br /> * 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. <br /> * Les extensions peuvent être vues comme un protocole 3.5 (entre la couche 3 et la couche 4). En effet, à part l'extension de &quot;proche en proche&quot;, 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 &lt;tt&gt;adresse de destination&lt;/tt&gt; du paquet IPv6). <br /> <br /> &lt;center&gt;<br /> [[image:2015_10_10_extensions_IPv6_v01.jpg|thumb|center|600px|Figure 2 : Enchaînement d'extensions.]]<br /> &lt;/center&gt;<br /> <br /> == Quelques exemples ==<br /> <br /> === Fragmentation ===<br /> La fragmentation, telle qu'elle est pratiquée dans IPv4, n'est pas très performante. Initialement, elle servait à rendre transparente les limitations physiques des supports de transmission. Dans IPv4, quand un routeur ne peut pas transmettre un paquet à cause de sa trop grande taille, et si le bit DF ''don't fragment'' est à 0, il découpe l'information à transmettre en fragments. Or, le réseau IP étant un réseau à datagrammes, il n'y a pas de possibilité de contrôler les fragments. Deux fragments successifs peuvent prendre deux chemins différents et, par conséquent, seul le destinataire peut effectuer le ré-assemblage. En conséquence, après la traversée d'un lien impliquant une fragmentation, le reste du réseau ne voit passer que des paquets de taille réduite. <br /> <br /> 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 1981 : Mécanisme de découverte du PMTU). En pratique, une taille de paquets de 1 500 octets est presque universelle.<br /> <br /> Il existe pourtant des cas où la fragmentation est nécessaire. Ainsi, une application telle que NFS sur UDP suppose que la fragmentation existe et produit des messages de taille quelconque. Comme on ne veut pas modifier ces applications, la couche réseau d'IPv6 doit aussi être capable de gérer la fragmentation. Pour réduire le travail des routeurs intermédiaires, la fragmentation se fera au niveau de la source et le ré-assemblage par le destinataire. Les informations utiles pour ces mécanismes (identification du paquet fragmenté, place du fragment) sont transportées dans une extension de fragmentation, représentée dans la figure 3. <br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_PMTU_5_v01.jpg|thumb|center|600px|Figure 3 : Format de l'extension de fragmentation.]]<br /> &lt;/center&gt;<br /> <br /> * Le champ longueur de l'extension est remplacé par un champ réservé, positionné pour l'instant à 0. Un champ de longueur est, car l'extension tient sur un seul mot de 64 bits et le premier mot n'est pas compté dans le calcul de longueur des extensions.<br /> * Le &lt;tt&gt;fragment offset&lt;/tt&gt; indique, lors du ré-assemblage, la position à laquelle les données du fragment doivent s'insérer. Ceci permet de résoudre les problèmes dus au déséquencement éventuel des datagrammes. Ce champ étant sur 13 bits, la taille des fragments, excepté le dernier, doit être multiple de 8 octets (alignement sur frontière de mots de 64 bits),<br /> * Le bit &lt;tt&gt;M&lt;/tt&gt; (More data) est à 1 sur les fragments intermédiaires et à 0 sur le fragment final,<br /> * Le champ &lt;tt&gt;identification&lt;/tt&gt; permet de repérer les fragments appartenant à un même paquet initial pour une source et une destination données.<br /> <br /> Le bit DF (Don't Fragment), de l'en-tête IPv4 n'est plus nécessaire. Si un paquet est trop grand, il y aura rejet par le routeur et émission d'un message ICMP.<br /> <br /> Dans IPv6, 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 les autres extensions et l'en-tête de niveau 4 ne seront présents que dans le premier fragment.<br /> <br /> Le mécanisme de gestion de la taille d'un paquet IPv6, selon les différents cas possibles, est approfondi dans l'activité suivante.<br /> <br /> === Extensions d'authentification (AH) et de confidentialité (ESP) ===<br /> <br /> 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.<br /> <br /> 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. C'est-à-dire, si un code d'authentification de message &lt;ref&gt;Code d'authentification de message, [https://fr.wikipedia.org/wiki/Code_d%27authentification_de_message Article Wikipedia]&lt;/ref&gt; est utilisé, il lui suffit 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.<br /> <br /> 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.<br /> <br /> 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 algorithme(s) de chiffrement, la ou les clé(s), et un indice de paramètres de sécurité.<br /> <br /> === Segment Routing Header (SRH) ===<br /> <br /> Cette extension est une des briques qui permet la mise en oeuvre de l'ingénierie de traffic et de la qualité de sevice 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 necessiter que le délai de bout en bout reste inférieur à 100ms, que le débit disponible soit au minimum de 2mbit/s et que le taux de perte reste inférieur à 1%. La solution habituellement mise en oeuvre pour le respect de ces métriques de qualité de service est RSVP-TE [Pujolle Les Réseaux 2014]. RSVP est un protocol de reservation de ressource sur les routeurs du chemin entre une source et une destination. La composante d'ingenerie de traffic permet notamment de choisir explicitement le chemin qui sera suivit par le paquet. Lorsqu'une appication aura besoin de reserver des ressources, un circuit MPLS sera établi et le protocole RSVP reservera les ressources sur l'ensemble des routeurs qui composent le chemin. La figure X résume ce comportement, le noeud A est la source du flot de vidéo conférence destiné à B, elle demande l'installation d'un chemin via MPLS. Le controleur determine 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 doivent accepter la requête.<br /> <br /> <br /> <br /> &lt;center&gt;<br /> [[image:Moocipv6-act24-SRH-rsvp2.png|thumb|center|400px|Figure 4 : Exemple d'utilisation de RSVP-TE pour assurer la qualité de service.]]<br /> &lt;/center&gt;<br /> <br /> <br /> 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. A 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 couteux en temps, en états, et en communication. Pour finir, si un des équipements 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 [[http://www.segment-routing.net/tutorials/2017-03-06-segment-routing-traffic-engineering-srte/]].<br /> <br /> Le concept de segment routing a été proposé pour palier à ces désavantages. Il permet de réduire l'intelligence des équipements du réseau. Un controleur choisi le chemin qui respecte les besoins de qualité de service du noeud. Le chemin à suivre ainsi que le traitement à associer aux paquets sont ensuite explicitement listés dans leurs entê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 à empreinter ou encore un service fournit par le routeur sur lequel transite le paquet. La séquence de segments que doit suivre le paquet peut être implémenté via une liste de label MPLS ou dans le cas d'en réseau IPv6 via l'option Segment Routing de l'entête [https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06]. Contrairement à MPLS, le segment routing avec IPv6 ne requière pas que tous les équipements traversés par le paquet soient compatibles avec cette option. Cela permet un déploiement progressif et de traverser plusieurs types de réseaux. Notons qu'il n'est pas necessaire d'inscrire l'integralité du chemin dans la liste. Les règles routage classique (IGP) s'appliquent pour acheminer le paquets entre les noeuds explicitement listés dans l'entête. Dans le cas de la figure 2, pour suivre le chemin G,H,I,K,N, il est seulement necessaire 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.a.d. B. Le paquet suit le plus court chemin entre I et B en l'occurence I,K,N. La taille de l'entête est donc limitée.<br /> <br /> <br /> <br /> &lt;center&gt;<br /> [[image:Moocipv6-act24-SRH-exemple.png|thumb|center|600px|Figure 5 :Exemple d'utilisation du Segment Routing pour l'ingénierie de trafic et la qualité de service.]]<br /> &lt;/center&gt;<br /> <br /> <br /> <br /> Le projet de RFC [https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06] prevoit qu'un segment soit représenté sur 128bit, c.a.d. autant qu'une adresse IPv6. Le nombre de segments inclus dans l'option SRH peut être déduit du champs Hdr Ext Len qui indique le nombre d'octets de l'option moins un. Le prochain segment à appliquer est indiqué par le champs Segments Left qui indique nombre de segments restant à appliquer au paquet. Le segment courant est inscrit dans le champs adresse de destination de l'entête IPv6. Lorsque le traitement associé à un segment est achevé, le prochain segment à traiter est copié dans le champs adresse de destination et le champs Segments Left est décrementé.<br /> <br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_IPv6_extension_routage_v02.jpg|thumb|center|400px|Figure 5 : Extension de routage par la source.]]<br /> &lt;/center&gt;<br /> <br /> L'option SRH est très proche de l'entête de routage défini dans la RFC2460 de IPv6. L'entête de routage devait notamment permettre le routage à la source qui conciste à lister les routeurs que devaient traverser le paquet au cours de son acheminement. Cette pratique a été dépréciée en 2007 par la RFC 5095 pour des raisons de sécurité. En effet cela permettait de generer de la congestion sur certains chemins, des attaques de déni de service, de contourner les règles de filtrages de certains parfeu ou encore d'atteindre des machines publiques accessibles (en DMZ) pour acceder à des machines qui ne sont pas directement accessibles. [A completer: http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf].<br /> <br /> Pour être accepté, l'option SRH devait donc garantir qu'elle ne serait pas vulnérable à ces attaques. Plusieurs cas d'utilisation sont décrits. Lorsque la SRH est générée au sein du réseau de l'opérateur (e.g. routeur de bordure) les attaques listées dans la RFC5095 sont innopérantes. Les routeurs de bordures doivent simplement filtrer les paquets venus de l'exterieur pour éviter de hôtes s'attribuent des privilèges ou provoque de la congestion sur certains lien. Lorsque les SRH sont générées en dehors du réseau de l'opérateur, la projet de RFC prévoit l'utilisation d'un mécanisme d'autentification de l'entête [RFC2104] (option HMAC). La clé de chiffrement de l'entête HMAC est distribuée au sein des noeuds autorisés à générer ou manipuler des entêtes SRH.<br /> <br /> <br /> <br /> ----------------------<br /> <br /> Cette extension permet d'imposer à un paquet une route différente de celle offerte par les politiques de routage présentes sur le réseau (cf. Figure 4). Pour l'instant, seul le routage par la source (&lt;tt&gt;type&lt;/tt&gt; = 0), similaire à l'option ''Loose Source Routing'' d'IPv4, est défini pour IPv6. La mobilité IPv6 a également introduit une autre extension de routage (&lt;tt&gt;type&lt;/tt&gt; = 2, optimisation dans le cas du mobile dans un réseau étranger).<br /> &lt;center&gt;<br /> [[image:2015_10_14_IPv6_extension_routage_v00.jpg|thumb|center|400px|Figure 4 : Routage par la source.]]<br /> &lt;/center&gt;<br /> Dans IPv4, le routage peut être strict (le routeur suivant, présent dans la liste, doit être un voisin directement accessible) ou libéral ''loose'' (un routeur peut utiliser les tables de routage pour joindre le routeur suivant, servant de relais). Dans IPv6, seul le routage libéral est autorisé. En effet, le routage strict était initialement mis en place surtout pour des raisons de sécurité. La source devait être absolument sûre du chemin pris par les paquets. Cette utilisation a maintenant disparu du réseau. <br /> <br /> Le principe du routage par la source, ou ''Source Routing'', dans IPv4, qui vient d’être rappelé, est le même pour IPv6. L'émetteur met, dans le champ &lt;tt&gt;destination&lt;/tt&gt; du paquet IPv6, l'adresse du premier routeur servant de relais. L'extension contient la suite de la liste des autres routeurs relais et le destinataire. Quand un routeur reçoit un paquet qui lui est adressé, comportant une extension de routage par la source, il permute son adresse avec l'adresse du prochain routeur et réémet le paquet vers cette adresse suivante.<br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_IPv6_extension_routage_v02.jpg|thumb|center|400px|Figure 5 : Extension de routage par la source.]]<br /> &lt;/center&gt;<br /> <br /> La figure 5 donne le format de l'extension de routage par la source : <br /> * Le champ de longueur &lt;tt&gt;Hdr Ext Len&lt;/tt&gt; de l'en-tête indique le nombre de mots de 64 bits qui composent l'extension. Pour l'extension de &lt;tt&gt;type&lt;/tt&gt; 0, cela correspond au nombre d'adresses présentes dans la liste, multiplié par 2. <br /> * Le champ &lt;tt&gt;Routing Type&lt;/tt&gt; indique la nature du routage. Pour l'instant, seul le routage par la source, de &lt;tt&gt;type&lt;/tt&gt; 0 est spécifié. La suite de l'en-tête correspond à ce &lt;tt&gt;type&lt;/tt&gt;. <br /> * Le champs &lt;tt&gt;Segment Left&lt;/tt&gt; est décrémenté après la traversée d'un routeur. Il indique le nombre d'équipements qui doivent encore être traversés. Il permet de trouver l'adresse qui devra être substituée. <br /> * Les 32 bits suivants sont inutilisés pour préserver l'alignement. <br /> * La liste, comprenant les routeurs à traverser et le destinataire, est fournie. Ces adresses ne peuvent pas être de type multicast.<br /> <br /> À noter : il n'y a pas de champ &lt;tt&gt;NH&lt;/tt&gt; dans TCP.<br /> <br /> Dans la figure 6, nous pouvons suivre l’évolution des changements des champs pendant la traversée du réseau du paquet IPv6 :<br /> * Noter l’évolution du champ &lt;tt&gt;Segment Left&lt;/tt&gt; qui pointe vers l’adresse du prochain routeur spécifié apte à traiter l’extension RH0.<br /> * Chaque routeur spécifié successif remplace l’adresse destination du datagramme avec l’adresse pointée par le champ &lt;tt&gt;Segment Left&lt;/tt&gt;. Une fois que le pointeur est décrémenté à 0, plus aucun changement ne sera effectué.<br /> * Les routeurs non spécifiés relaient les paquets de manière transparente.<br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_IPv6_extension_RH0_04.jpg|thumb|center|665px|Figure 6 : Extension de routage.]]<br /> &lt;/center&gt;<br /> <br /> == Conclusion ==<br /> 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 communications 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.<br /> <br /> 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 pris en compte dans le traitement des paquets, notamment le filtrage sur les valeurs du champ ''Next Header'' de l'en-tête IPv6.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin==<br /> Vous pouvez approfondir vos connaissances en consultant les documents de ce paragraphe.<br /> RFC et leur analyse par S. Bortzmeyer :<br /> * RFC 1981 : Path MTU Discovery for IP version 6<br /> * RFC 2460 : Internet Protocol, Version 6 (IPv6) Specification [http://www.bortzmeyer.org/2460.html Analyse]<br /> * RFC 4302 : IP Authentication Header<br /> * RFC 4303 : IP Encapsulating Security Payload (ESP)<br /> * RFC 5095 : Deprecation of Type 0 Routing Headers in IPv6 Specification [http://www.bortzmeyer.org/5095.html Analyse]<br /> * RFC 7045 : Transmission and Processing of IPv6 Extension Headers [http://www.bortzmeyer.org/7045.html Analyse]<br /> * RFC 7872 : Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World [http://www.bortzmeyer.org/7872.html Analyse]<br /> * [http://livre.g6.asso.fr/index.php/S%C3%A9curit%C3%A9 Chapitre Sécurité du livre &quot;IPv6, Théorie et Pratique&quot;]</div> Ptournoux2 http://livre.g6.asso.fr/index.php?title=File:Moocipv6-act24-SRH-rsvp2.png&diff=14919 File:Moocipv6-act24-SRH-rsvp2.png 2017-04-24T10:36:41Z <p>Ptournoux2: Exemple d'utilisation de RSVP-TE avec MPLS en vue d'introduire le Segment Routing.</p> <hr /> <div>Exemple d'utilisation de RSVP-TE avec MPLS en vue d'introduire le Segment Routing.</div> Ptournoux2 http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act24-s6&diff=14918 MOOC:Compagnon Act24-s6 2017-04-24T10:32:24Z <p>Ptournoux2: /* Segment Routing Header (SRH) */</p> <hr /> <div>__NOTOC__ <br /> =Activité 24 : Le mécanisme d’extension de l'en-tête IPv6=<br /> <br /> == Introduction ==<br /> <br /> 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 :<br /> * soit par le destinataire du paquet IPv6,<br /> * soit par les routeurs intermédiaires en charge de l’acheminement du paquet IPv6.<br /> <br /> De nombreuses extensions ont été définies, afin d'assurer des fonctions comme : <br /> * le routage par la source,<br /> * la gestion de la fragmentation,<br /> * la confidentialité des communications (mécanisme ''ipsec''),<br /> * etc. <br /> <br /> 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.<br /> <br /> == Principe des extensions IPv6==<br /> <br /> 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).<br /> Une extension a une longueur multiple de 8 octets (64 bits). Elle commence par un champ &lt;tt&gt;Next header&lt;/tt&gt; qui définit sur 1 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.<br /> <br /> 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.<br /> <br /> '''''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.''<br /> <br /> Une présentation illustrée des extensionsIPv6 peut être consultée sur le site de Cisco&lt;ref&gt;Cisco (2006) White paper.[http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html IPv6 Extension Headers Review and Considerations]&lt;/ref&gt;.<br /> <br /> == Le champ ''Next Header'' ==<br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_ipv6_header_next-header_v02.jpg|thumb|right|300px|Figure 1 : Localisation du champ &lt;tt&gt;Next Header&lt;/tt&gt; dans l'en-tête IPv6.]]<br /> &lt;/center&gt;<br /> Le champ &lt;tt&gt;Next Header&lt;/tt&gt; 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 :<br /> &lt;center&gt;{{MOOC_Valeurs_du_champ_en-tête_suivant}}<br /> &lt;/center&gt;<br /> <br /> == Intégration des extensions d’en-tête dans le paquet IPv6==<br /> 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: <br /> * extensions impliquant tous les routeurs intermédiaires : ''Hop-by-Hop'' ;<br /> * extensions impliquant seulement certains routeurs désignés : ''Routing'' ;<br /> * extension impliquant le destinataire : ''Authentication'', ''Encapsulating Security Payload'', Fragmentation, Destination.<br /> <br /> <br /> 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 &lt;tt&gt;en-tête suivant&lt;/tt&gt; et un champ &lt;tt&gt;longueur&lt;/tt&gt;. Le premier paquet ne contient pas d'extension ; le champ &lt;tt&gt;en-tête suivant&lt;/tt&gt; pointe sur ICMPv6. Le second paquet ne contient pas d'extension ; le champ &lt;tt&gt;en-tête suivant&lt;/tt&gt; 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. <br /> * 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.<br /> * 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. <br /> * Les extensions peuvent être vues comme un protocole 3.5 (entre la couche 3 et la couche 4). En effet, à part l'extension de &quot;proche en proche&quot;, 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 &lt;tt&gt;adresse de destination&lt;/tt&gt; du paquet IPv6). <br /> <br /> &lt;center&gt;<br /> [[image:2015_10_10_extensions_IPv6_v01.jpg|thumb|center|600px|Figure 2 : Enchaînement d'extensions.]]<br /> &lt;/center&gt;<br /> <br /> == Quelques exemples ==<br /> <br /> === Fragmentation ===<br /> La fragmentation, telle qu'elle est pratiquée dans IPv4, n'est pas très performante. Initialement, elle servait à rendre transparente les limitations physiques des supports de transmission. Dans IPv4, quand un routeur ne peut pas transmettre un paquet à cause de sa trop grande taille, et si le bit DF ''don't fragment'' est à 0, il découpe l'information à transmettre en fragments. Or, le réseau IP étant un réseau à datagrammes, il n'y a pas de possibilité de contrôler les fragments. Deux fragments successifs peuvent prendre deux chemins différents et, par conséquent, seul le destinataire peut effectuer le ré-assemblage. En conséquence, après la traversée d'un lien impliquant une fragmentation, le reste du réseau ne voit passer que des paquets de taille réduite. <br /> <br /> 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 1981 : Mécanisme de découverte du PMTU). En pratique, une taille de paquets de 1 500 octets est presque universelle.<br /> <br /> Il existe pourtant des cas où la fragmentation est nécessaire. Ainsi, une application telle que NFS sur UDP suppose que la fragmentation existe et produit des messages de taille quelconque. Comme on ne veut pas modifier ces applications, la couche réseau d'IPv6 doit aussi être capable de gérer la fragmentation. Pour réduire le travail des routeurs intermédiaires, la fragmentation se fera au niveau de la source et le ré-assemblage par le destinataire. Les informations utiles pour ces mécanismes (identification du paquet fragmenté, place du fragment) sont transportées dans une extension de fragmentation, représentée dans la figure 3. <br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_PMTU_5_v01.jpg|thumb|center|600px|Figure 3 : Format de l'extension de fragmentation.]]<br /> &lt;/center&gt;<br /> <br /> * Le champ longueur de l'extension est remplacé par un champ réservé, positionné pour l'instant à 0. Un champ de longueur est, car l'extension tient sur un seul mot de 64 bits et le premier mot n'est pas compté dans le calcul de longueur des extensions.<br /> * Le &lt;tt&gt;fragment offset&lt;/tt&gt; indique, lors du ré-assemblage, la position à laquelle les données du fragment doivent s'insérer. Ceci permet de résoudre les problèmes dus au déséquencement éventuel des datagrammes. Ce champ étant sur 13 bits, la taille des fragments, excepté le dernier, doit être multiple de 8 octets (alignement sur frontière de mots de 64 bits),<br /> * Le bit &lt;tt&gt;M&lt;/tt&gt; (More data) est à 1 sur les fragments intermédiaires et à 0 sur le fragment final,<br /> * Le champ &lt;tt&gt;identification&lt;/tt&gt; permet de repérer les fragments appartenant à un même paquet initial pour une source et une destination données.<br /> <br /> Le bit DF (Don't Fragment), de l'en-tête IPv4 n'est plus nécessaire. Si un paquet est trop grand, il y aura rejet par le routeur et émission d'un message ICMP.<br /> <br /> Dans IPv6, 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 les autres extensions et l'en-tête de niveau 4 ne seront présents que dans le premier fragment.<br /> <br /> Le mécanisme de gestion de la taille d'un paquet IPv6, selon les différents cas possibles, est approfondi dans l'activité suivante.<br /> <br /> === Extensions d'authentification (AH) et de confidentialité (ESP) ===<br /> <br /> 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.<br /> <br /> 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. C'est-à-dire, si un code d'authentification de message &lt;ref&gt;Code d'authentification de message, [https://fr.wikipedia.org/wiki/Code_d%27authentification_de_message Article Wikipedia]&lt;/ref&gt; est utilisé, il lui suffit 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.<br /> <br /> 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.<br /> <br /> 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 algorithme(s) de chiffrement, la ou les clé(s), et un indice de paramètres de sécurité.<br /> <br /> === Segment Routing Header (SRH) ===<br /> <br /> Cette extension est une des briques qui permet la mise en oeuvre de l'ingénierie de traffic et de la qualité de sevice 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 necessiter que le délai de bout en bout reste inférieur à 100ms, que le débit disponible soit au minimum de 2mbit/s et que le taux de perte reste inférieur à 1%. La solution habituellement mise en oeuvre pour le respect de ces métriques de qualité de service est RSVP-TE [Pujolle Les Réseaux 2014]. RSVP est un protocol de reservation de ressource sur les routeurs du chemin entre une source et une destination. La composante d'ingenerie de traffic permet notamment de choisir explicitement le chemin qui sera suivit par le paquet. Lorsqu'une appication aura besoin de reserver des ressources, un circuit MPLS sera établi et le protocole RSVP reservera les ressources sur l'ensemble des routeurs qui composent le chemin. La figure X résume ce comportement, le noeud A est la source du flot de vidéo conférence destiné à B, elle demande l'installation d'un chemin via MPLS. Le controleur determine 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 doivent accepter la requête.<br /> <br /> <br /> <br /> &lt;center&gt;<br /> [[image:Moocipv6-act24-SRH-rsvp.png|thumb|center|400px|Figure 4 : Exemple d'utilisation de RSVP-TE pour assurer la qualité de service.]]<br /> &lt;/center&gt;<br /> <br /> <br /> 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. A 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 couteux en temps, en états, et en communication. Pour finir, si un des équipements 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 [[http://www.segment-routing.net/tutorials/2017-03-06-segment-routing-traffic-engineering-srte/]].<br /> <br /> Le concept de segment routing a été proposé pour palier à ces désavantages. Il permet de réduire l'intelligence des équipements du réseau. Un controleur choisi le chemin qui respecte les besoins de qualité de service du noeud. Le chemin à suivre ainsi que le traitement à associer aux paquets sont ensuite explicitement listés dans leurs entê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 à empreinter ou encore un service fournit par le routeur sur lequel transite le paquet. La séquence de segments que doit suivre le paquet peut être implémenté via une liste de label MPLS ou dans le cas d'en réseau IPv6 via l'option Segment Routing de l'entête [https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06]. Contrairement à MPLS, le segment routing avec IPv6 ne requière pas que tous les équipements traversés par le paquet soient compatibles avec cette option. Cela permet un déploiement progressif et de traverser plusieurs types de réseaux. Notons qu'il n'est pas necessaire d'inscrire l'integralité du chemin dans la liste. Les règles routage classique (IGP) s'appliquent pour acheminer le paquets entre les noeuds explicitement listés dans l'entête. Dans le cas de la figure 2, pour suivre le chemin G,H,I,K,N, il est seulement necessaire 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.a.d. B. Le paquet suit le plus court chemin entre I et B en l'occurence I,K,N. La taille de l'entête est donc limitée.<br /> <br /> <br /> <br /> &lt;center&gt;<br /> [[image:Moocipv6-act24-SRH-exemple.png|thumb|center|600px|Figure 5 :Exemple d'utilisation du Segment Routing pour l'ingénierie de trafic et la qualité de service.]]<br /> &lt;/center&gt;<br /> <br /> <br /> <br /> Le projet de RFC [https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06] prevoit qu'un segment soit représenté sur 128bit, c.a.d. autant qu'une adresse IPv6. Le nombre de segments inclus dans l'option SRH peut être déduit du champs Hdr Ext Len qui indique le nombre d'octets de l'option moins un. Le prochain segment à appliquer est indiqué par le champs Segments Left qui indique nombre de segments restant à appliquer au paquet. Le segment courant est inscrit dans le champs adresse de destination de l'entête IPv6. Lorsque le traitement associé à un segment est achevé, le prochain segment à traiter est copié dans le champs adresse de destination et le champs Segments Left est décrementé.<br /> <br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_IPv6_extension_routage_v02.jpg|thumb|center|400px|Figure 5 : Extension de routage par la source.]]<br /> &lt;/center&gt;<br /> <br /> L'option SRH est très proche de l'entête de routage défini dans la RFC2460 de IPv6. L'entête de routage devait notamment permettre le routage à la source qui conciste à lister les routeurs que devaient traverser le paquet au cours de son acheminement. Cette pratique a été dépréciée en 2007 par la RFC 5095 pour des raisons de sécurité. En effet cela permettait de generer de la congestion sur certains chemins, des attaques de déni de service, de contourner les règles de filtrages de certains parfeu ou encore d'atteindre des machines publiques accessibles (en DMZ) pour acceder à des machines qui ne sont pas directement accessibles. [A completer: http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf].<br /> <br /> Pour être accepté, l'option SRH devait donc garantir qu'elle ne serait pas vulnérable à ces attaques. Plusieurs cas d'utilisation sont décrits. Lorsque la SRH est générée au sein du réseau de l'opérateur (e.g. routeur de bordure) les attaques listées dans la RFC5095 sont innopérantes. Les routeurs de bordures doivent simplement filtrer les paquets venus de l'exterieur pour éviter de hôtes s'attribuent des privilèges ou provoque de la congestion sur certains lien. Lorsque les SRH sont générées en dehors du réseau de l'opérateur, la projet de RFC prévoit l'utilisation d'un mécanisme d'autentification de l'entête [RFC2104] (option HMAC). La clé de chiffrement de l'entête HMAC est distribuée au sein des noeuds autorisés à générer ou manipuler des entêtes SRH.<br /> <br /> <br /> <br /> ----------------------<br /> <br /> Cette extension permet d'imposer à un paquet une route différente de celle offerte par les politiques de routage présentes sur le réseau (cf. Figure 4). Pour l'instant, seul le routage par la source (&lt;tt&gt;type&lt;/tt&gt; = 0), similaire à l'option ''Loose Source Routing'' d'IPv4, est défini pour IPv6. La mobilité IPv6 a également introduit une autre extension de routage (&lt;tt&gt;type&lt;/tt&gt; = 2, optimisation dans le cas du mobile dans un réseau étranger).<br /> &lt;center&gt;<br /> [[image:2015_10_14_IPv6_extension_routage_v00.jpg|thumb|center|400px|Figure 4 : Routage par la source.]]<br /> &lt;/center&gt;<br /> Dans IPv4, le routage peut être strict (le routeur suivant, présent dans la liste, doit être un voisin directement accessible) ou libéral ''loose'' (un routeur peut utiliser les tables de routage pour joindre le routeur suivant, servant de relais). Dans IPv6, seul le routage libéral est autorisé. En effet, le routage strict était initialement mis en place surtout pour des raisons de sécurité. La source devait être absolument sûre du chemin pris par les paquets. Cette utilisation a maintenant disparu du réseau. <br /> <br /> Le principe du routage par la source, ou ''Source Routing'', dans IPv4, qui vient d’être rappelé, est le même pour IPv6. L'émetteur met, dans le champ &lt;tt&gt;destination&lt;/tt&gt; du paquet IPv6, l'adresse du premier routeur servant de relais. L'extension contient la suite de la liste des autres routeurs relais et le destinataire. Quand un routeur reçoit un paquet qui lui est adressé, comportant une extension de routage par la source, il permute son adresse avec l'adresse du prochain routeur et réémet le paquet vers cette adresse suivante.<br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_IPv6_extension_routage_v02.jpg|thumb|center|400px|Figure 5 : Extension de routage par la source.]]<br /> &lt;/center&gt;<br /> <br /> La figure 5 donne le format de l'extension de routage par la source : <br /> * Le champ de longueur &lt;tt&gt;Hdr Ext Len&lt;/tt&gt; de l'en-tête indique le nombre de mots de 64 bits qui composent l'extension. Pour l'extension de &lt;tt&gt;type&lt;/tt&gt; 0, cela correspond au nombre d'adresses présentes dans la liste, multiplié par 2. <br /> * Le champ &lt;tt&gt;Routing Type&lt;/tt&gt; indique la nature du routage. Pour l'instant, seul le routage par la source, de &lt;tt&gt;type&lt;/tt&gt; 0 est spécifié. La suite de l'en-tête correspond à ce &lt;tt&gt;type&lt;/tt&gt;. <br /> * Le champs &lt;tt&gt;Segment Left&lt;/tt&gt; est décrémenté après la traversée d'un routeur. Il indique le nombre d'équipements qui doivent encore être traversés. Il permet de trouver l'adresse qui devra être substituée. <br /> * Les 32 bits suivants sont inutilisés pour préserver l'alignement. <br /> * La liste, comprenant les routeurs à traverser et le destinataire, est fournie. Ces adresses ne peuvent pas être de type multicast.<br /> <br /> À noter : il n'y a pas de champ &lt;tt&gt;NH&lt;/tt&gt; dans TCP.<br /> <br /> Dans la figure 6, nous pouvons suivre l’évolution des changements des champs pendant la traversée du réseau du paquet IPv6 :<br /> * Noter l’évolution du champ &lt;tt&gt;Segment Left&lt;/tt&gt; qui pointe vers l’adresse du prochain routeur spécifié apte à traiter l’extension RH0.<br /> * Chaque routeur spécifié successif remplace l’adresse destination du datagramme avec l’adresse pointée par le champ &lt;tt&gt;Segment Left&lt;/tt&gt;. Une fois que le pointeur est décrémenté à 0, plus aucun changement ne sera effectué.<br /> * Les routeurs non spécifiés relaient les paquets de manière transparente.<br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_IPv6_extension_RH0_04.jpg|thumb|center|665px|Figure 6 : Extension de routage.]]<br /> &lt;/center&gt;<br /> <br /> == Conclusion ==<br /> 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 communications 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.<br /> <br /> 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 pris en compte dans le traitement des paquets, notamment le filtrage sur les valeurs du champ ''Next Header'' de l'en-tête IPv6.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin==<br /> Vous pouvez approfondir vos connaissances en consultant les documents de ce paragraphe.<br /> RFC et leur analyse par S. Bortzmeyer :<br /> * RFC 1981 : Path MTU Discovery for IP version 6<br /> * RFC 2460 : Internet Protocol, Version 6 (IPv6) Specification [http://www.bortzmeyer.org/2460.html Analyse]<br /> * RFC 4302 : IP Authentication Header<br /> * RFC 4303 : IP Encapsulating Security Payload (ESP)<br /> * RFC 5095 : Deprecation of Type 0 Routing Headers in IPv6 Specification [http://www.bortzmeyer.org/5095.html Analyse]<br /> * RFC 7045 : Transmission and Processing of IPv6 Extension Headers [http://www.bortzmeyer.org/7045.html Analyse]<br /> * RFC 7872 : Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World [http://www.bortzmeyer.org/7872.html Analyse]<br /> * [http://livre.g6.asso.fr/index.php/S%C3%A9curit%C3%A9 Chapitre Sécurité du livre &quot;IPv6, Théorie et Pratique&quot;]</div> Ptournoux2 http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act24-s6&diff=14917 MOOC:Compagnon Act24-s6 2017-04-24T10:28:12Z <p>Ptournoux2: /* Segment Routing Header (SRH) */</p> <hr /> <div>__NOTOC__ <br /> =Activité 24 : Le mécanisme d’extension de l'en-tête IPv6=<br /> <br /> == Introduction ==<br /> <br /> 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 :<br /> * soit par le destinataire du paquet IPv6,<br /> * soit par les routeurs intermédiaires en charge de l’acheminement du paquet IPv6.<br /> <br /> De nombreuses extensions ont été définies, afin d'assurer des fonctions comme : <br /> * le routage par la source,<br /> * la gestion de la fragmentation,<br /> * la confidentialité des communications (mécanisme ''ipsec''),<br /> * etc. <br /> <br /> 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.<br /> <br /> == Principe des extensions IPv6==<br /> <br /> 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).<br /> Une extension a une longueur multiple de 8 octets (64 bits). Elle commence par un champ &lt;tt&gt;Next header&lt;/tt&gt; qui définit sur 1 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.<br /> <br /> 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.<br /> <br /> '''''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.''<br /> <br /> Une présentation illustrée des extensionsIPv6 peut être consultée sur le site de Cisco&lt;ref&gt;Cisco (2006) White paper.[http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html IPv6 Extension Headers Review and Considerations]&lt;/ref&gt;.<br /> <br /> == Le champ ''Next Header'' ==<br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_ipv6_header_next-header_v02.jpg|thumb|right|300px|Figure 1 : Localisation du champ &lt;tt&gt;Next Header&lt;/tt&gt; dans l'en-tête IPv6.]]<br /> &lt;/center&gt;<br /> Le champ &lt;tt&gt;Next Header&lt;/tt&gt; 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 :<br /> &lt;center&gt;{{MOOC_Valeurs_du_champ_en-tête_suivant}}<br /> &lt;/center&gt;<br /> <br /> == Intégration des extensions d’en-tête dans le paquet IPv6==<br /> 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: <br /> * extensions impliquant tous les routeurs intermédiaires : ''Hop-by-Hop'' ;<br /> * extensions impliquant seulement certains routeurs désignés : ''Routing'' ;<br /> * extension impliquant le destinataire : ''Authentication'', ''Encapsulating Security Payload'', Fragmentation, Destination.<br /> <br /> <br /> 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 &lt;tt&gt;en-tête suivant&lt;/tt&gt; et un champ &lt;tt&gt;longueur&lt;/tt&gt;. Le premier paquet ne contient pas d'extension ; le champ &lt;tt&gt;en-tête suivant&lt;/tt&gt; pointe sur ICMPv6. Le second paquet ne contient pas d'extension ; le champ &lt;tt&gt;en-tête suivant&lt;/tt&gt; 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. <br /> * 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.<br /> * 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. <br /> * Les extensions peuvent être vues comme un protocole 3.5 (entre la couche 3 et la couche 4). En effet, à part l'extension de &quot;proche en proche&quot;, 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 &lt;tt&gt;adresse de destination&lt;/tt&gt; du paquet IPv6). <br /> <br /> &lt;center&gt;<br /> [[image:2015_10_10_extensions_IPv6_v01.jpg|thumb|center|600px|Figure 2 : Enchaînement d'extensions.]]<br /> &lt;/center&gt;<br /> <br /> == Quelques exemples ==<br /> <br /> === Fragmentation ===<br /> La fragmentation, telle qu'elle est pratiquée dans IPv4, n'est pas très performante. Initialement, elle servait à rendre transparente les limitations physiques des supports de transmission. Dans IPv4, quand un routeur ne peut pas transmettre un paquet à cause de sa trop grande taille, et si le bit DF ''don't fragment'' est à 0, il découpe l'information à transmettre en fragments. Or, le réseau IP étant un réseau à datagrammes, il n'y a pas de possibilité de contrôler les fragments. Deux fragments successifs peuvent prendre deux chemins différents et, par conséquent, seul le destinataire peut effectuer le ré-assemblage. En conséquence, après la traversée d'un lien impliquant une fragmentation, le reste du réseau ne voit passer que des paquets de taille réduite. <br /> <br /> 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 1981 : Mécanisme de découverte du PMTU). En pratique, une taille de paquets de 1 500 octets est presque universelle.<br /> <br /> Il existe pourtant des cas où la fragmentation est nécessaire. Ainsi, une application telle que NFS sur UDP suppose que la fragmentation existe et produit des messages de taille quelconque. Comme on ne veut pas modifier ces applications, la couche réseau d'IPv6 doit aussi être capable de gérer la fragmentation. Pour réduire le travail des routeurs intermédiaires, la fragmentation se fera au niveau de la source et le ré-assemblage par le destinataire. Les informations utiles pour ces mécanismes (identification du paquet fragmenté, place du fragment) sont transportées dans une extension de fragmentation, représentée dans la figure 3. <br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_PMTU_5_v01.jpg|thumb|center|600px|Figure 3 : Format de l'extension de fragmentation.]]<br /> &lt;/center&gt;<br /> <br /> * Le champ longueur de l'extension est remplacé par un champ réservé, positionné pour l'instant à 0. Un champ de longueur est, car l'extension tient sur un seul mot de 64 bits et le premier mot n'est pas compté dans le calcul de longueur des extensions.<br /> * Le &lt;tt&gt;fragment offset&lt;/tt&gt; indique, lors du ré-assemblage, la position à laquelle les données du fragment doivent s'insérer. Ceci permet de résoudre les problèmes dus au déséquencement éventuel des datagrammes. Ce champ étant sur 13 bits, la taille des fragments, excepté le dernier, doit être multiple de 8 octets (alignement sur frontière de mots de 64 bits),<br /> * Le bit &lt;tt&gt;M&lt;/tt&gt; (More data) est à 1 sur les fragments intermédiaires et à 0 sur le fragment final,<br /> * Le champ &lt;tt&gt;identification&lt;/tt&gt; permet de repérer les fragments appartenant à un même paquet initial pour une source et une destination données.<br /> <br /> Le bit DF (Don't Fragment), de l'en-tête IPv4 n'est plus nécessaire. Si un paquet est trop grand, il y aura rejet par le routeur et émission d'un message ICMP.<br /> <br /> Dans IPv6, 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 les autres extensions et l'en-tête de niveau 4 ne seront présents que dans le premier fragment.<br /> <br /> Le mécanisme de gestion de la taille d'un paquet IPv6, selon les différents cas possibles, est approfondi dans l'activité suivante.<br /> <br /> === Extensions d'authentification (AH) et de confidentialité (ESP) ===<br /> <br /> 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.<br /> <br /> 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. C'est-à-dire, si un code d'authentification de message &lt;ref&gt;Code d'authentification de message, [https://fr.wikipedia.org/wiki/Code_d%27authentification_de_message Article Wikipedia]&lt;/ref&gt; est utilisé, il lui suffit 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.<br /> <br /> 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.<br /> <br /> 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 algorithme(s) de chiffrement, la ou les clé(s), et un indice de paramètres de sécurité.<br /> <br /> === Segment Routing Header (SRH) ===<br /> <br /> Cette extension est une des briques qui permet la mise en oeuvre de l'ingénierie de traffic et de la qualité de sevice 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 necessiter que le délai de bout en bout reste inférieur à 100ms, que le débit disponible soit au minimum de 2mbit/s et que le taux de perte reste inférieur à 1%. La solution habituellement mise en oeuvre pour le respect de ces métriques de qualité de service est RSVP-TE [Pujolle Les Réseaux 2014]. RSVP est un protocol de reservation de ressource sur les routeurs du chemin entre une source et une destination. La composante d'ingenerie de traffic permet notamment de choisir explicitement le chemin qui sera suivit par le paquet. Lorsqu'une appication aura besoin de reserver des ressources, un circuit MPLS sera établi et le protocole RSVP reservera les ressources sur l'ensemble des routeurs qui composent le chemin. La figure X résume ce comportement, le noeud A est la source du flot de vidéo conférence destiné à B, elle demande l'installation d'un chemin via MPLS. Le controleur determine 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 doivent accepter la requête.<br /> <br /> FIGURE RSVP<br /> <br /> <br /> &lt;center&gt;<br /> [[image:Moocipv6-act24-SRH-rsvp.png|thumb|center|400px|Figure 5 : Exemple d'utilisation de RSVP-TE pour assurer la qualité de service.]]<br /> &lt;/center&gt;<br /> <br /> <br /> 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. A 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 couteux en temps, en états, et en communication. Pour finir, si un des équipements 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 [[http://www.segment-routing.net/tutorials/2017-03-06-segment-routing-traffic-engineering-srte/]].<br /> <br /> Le concept de segment routing a été proposé pour palier à ces désavantages. Il permet de réduire l'intelligence des équipements du réseau. Un controleur choisi le chemin qui respecte les besoins de qualité de service du noeud. Le chemin à suivre ainsi que le traitement à associer aux paquets sont ensuite explicitement listés dans leurs entê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 à empreinter ou encore un service fournit par le routeur sur lequel transite le paquet. La séquence de segments que doit suivre le paquet peut être implémenté via une liste de label MPLS ou dans le cas d'en réseau IPv6 via l'option Segment Routing de l'entête [https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06]. Contrairement à MPLS, le segment routing avec IPv6 ne requière pas que tous les équipements traversés par le paquet soient compatibles avec cette option. Cela permet un déploiement progressif et de traverser plusieurs types de réseaux. Notons qu'il n'est pas necessaire d'inscrire l'integralité du chemin dans la liste. Les règles routage classique (IGP) s'appliquent pour acheminer le paquets entre les noeuds explicitement listés dans l'entête. Dans le cas de la figure 2, pour suivre le chemin G,H,I,K,N, il est seulement necessaire 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.a.d. B. Le paquet suit le plus court chemin entre I et B en l'occurence I,K,N. La taille de l'entête est donc limitée.<br /> <br /> <br /> <br /> Le projet de RFC [https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06] prevoit qu'un segment soit représenté sur 128bit, c.a.d. autant qu'une adresse IPv6. Le nombre de segments inclus dans l'option SRH peut être déduit du champs Hdr Ext Len qui indique le nombre d'octets de l'option moins un. Le prochain segment à appliquer est indiqué par le champs Segments Left qui indique nombre de segments restant à appliquer au paquet. Le segment courant est inscrit dans le champs adresse de destination de l'entête IPv6. Lorsque le traitement associé à un segment est achevé, le prochain segment à traiter est copié dans le champs adresse de destination et le champs Segments Left est décrementé.<br /> <br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_IPv6_extension_routage_v02.jpg|thumb|center|400px|Figure 5 : Extension de routage par la source.]]<br /> &lt;/center&gt;<br /> <br /> L'option SRH est très proche de l'entête de routage défini dans la RFC2460 de IPv6. L'entête de routage devait notamment permettre le routage à la source qui conciste à lister les routeurs que devaient traverser le paquet au cours de son acheminement. Cette pratique a été dépréciée en 2007 par la RFC 5095 pour des raisons de sécurité. En effet cela permettait de generer de la congestion sur certains chemins, des attaques de déni de service, de contourner les règles de filtrages de certains parfeu ou encore d'atteindre des machines publiques accessibles (en DMZ) pour acceder à des machines qui ne sont pas directement accessibles. [A completer: http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf].<br /> <br /> Pour être accepté, l'option SRH devait donc garantir qu'elle ne serait pas vulnérable à ces attaques. Plusieurs cas d'utilisation sont décrits. Lorsque la SRH est générée au sein du réseau de l'opérateur (e.g. routeur de bordure) les attaques listées dans la RFC5095 sont innopérantes. Les routeurs de bordures doivent simplement filtrer les paquets venus de l'exterieur pour éviter de hôtes s'attribuent des privilèges ou provoque de la congestion sur certains lien. Lorsque les SRH sont générées en dehors du réseau de l'opérateur, la projet de RFC prévoit l'utilisation d'un mécanisme d'autentification de l'entête [RFC2104] (option HMAC). La clé de chiffrement de l'entête HMAC est distribuée au sein des noeuds autorisés à générer ou manipuler des entêtes SRH.<br /> <br /> <br /> <br /> ----------------------<br /> <br /> Cette extension permet d'imposer à un paquet une route différente de celle offerte par les politiques de routage présentes sur le réseau (cf. Figure 4). Pour l'instant, seul le routage par la source (&lt;tt&gt;type&lt;/tt&gt; = 0), similaire à l'option ''Loose Source Routing'' d'IPv4, est défini pour IPv6. La mobilité IPv6 a également introduit une autre extension de routage (&lt;tt&gt;type&lt;/tt&gt; = 2, optimisation dans le cas du mobile dans un réseau étranger).<br /> &lt;center&gt;<br /> [[image:2015_10_14_IPv6_extension_routage_v00.jpg|thumb|center|400px|Figure 4 : Routage par la source.]]<br /> &lt;/center&gt;<br /> Dans IPv4, le routage peut être strict (le routeur suivant, présent dans la liste, doit être un voisin directement accessible) ou libéral ''loose'' (un routeur peut utiliser les tables de routage pour joindre le routeur suivant, servant de relais). Dans IPv6, seul le routage libéral est autorisé. En effet, le routage strict était initialement mis en place surtout pour des raisons de sécurité. La source devait être absolument sûre du chemin pris par les paquets. Cette utilisation a maintenant disparu du réseau. <br /> <br /> Le principe du routage par la source, ou ''Source Routing'', dans IPv4, qui vient d’être rappelé, est le même pour IPv6. L'émetteur met, dans le champ &lt;tt&gt;destination&lt;/tt&gt; du paquet IPv6, l'adresse du premier routeur servant de relais. L'extension contient la suite de la liste des autres routeurs relais et le destinataire. Quand un routeur reçoit un paquet qui lui est adressé, comportant une extension de routage par la source, il permute son adresse avec l'adresse du prochain routeur et réémet le paquet vers cette adresse suivante.<br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_IPv6_extension_routage_v02.jpg|thumb|center|400px|Figure 5 : Extension de routage par la source.]]<br /> &lt;/center&gt;<br /> <br /> La figure 5 donne le format de l'extension de routage par la source : <br /> * Le champ de longueur &lt;tt&gt;Hdr Ext Len&lt;/tt&gt; de l'en-tête indique le nombre de mots de 64 bits qui composent l'extension. Pour l'extension de &lt;tt&gt;type&lt;/tt&gt; 0, cela correspond au nombre d'adresses présentes dans la liste, multiplié par 2. <br /> * Le champ &lt;tt&gt;Routing Type&lt;/tt&gt; indique la nature du routage. Pour l'instant, seul le routage par la source, de &lt;tt&gt;type&lt;/tt&gt; 0 est spécifié. La suite de l'en-tête correspond à ce &lt;tt&gt;type&lt;/tt&gt;. <br /> * Le champs &lt;tt&gt;Segment Left&lt;/tt&gt; est décrémenté après la traversée d'un routeur. Il indique le nombre d'équipements qui doivent encore être traversés. Il permet de trouver l'adresse qui devra être substituée. <br /> * Les 32 bits suivants sont inutilisés pour préserver l'alignement. <br /> * La liste, comprenant les routeurs à traverser et le destinataire, est fournie. Ces adresses ne peuvent pas être de type multicast.<br /> <br /> À noter : il n'y a pas de champ &lt;tt&gt;NH&lt;/tt&gt; dans TCP.<br /> <br /> Dans la figure 6, nous pouvons suivre l’évolution des changements des champs pendant la traversée du réseau du paquet IPv6 :<br /> * Noter l’évolution du champ &lt;tt&gt;Segment Left&lt;/tt&gt; qui pointe vers l’adresse du prochain routeur spécifié apte à traiter l’extension RH0.<br /> * Chaque routeur spécifié successif remplace l’adresse destination du datagramme avec l’adresse pointée par le champ &lt;tt&gt;Segment Left&lt;/tt&gt;. Une fois que le pointeur est décrémenté à 0, plus aucun changement ne sera effectué.<br /> * Les routeurs non spécifiés relaient les paquets de manière transparente.<br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_IPv6_extension_RH0_04.jpg|thumb|center|665px|Figure 6 : Extension de routage.]]<br /> &lt;/center&gt;<br /> <br /> == Conclusion ==<br /> 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 communications 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.<br /> <br /> 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 pris en compte dans le traitement des paquets, notamment le filtrage sur les valeurs du champ ''Next Header'' de l'en-tête IPv6.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin==<br /> Vous pouvez approfondir vos connaissances en consultant les documents de ce paragraphe.<br /> RFC et leur analyse par S. Bortzmeyer :<br /> * RFC 1981 : Path MTU Discovery for IP version 6<br /> * RFC 2460 : Internet Protocol, Version 6 (IPv6) Specification [http://www.bortzmeyer.org/2460.html Analyse]<br /> * RFC 4302 : IP Authentication Header<br /> * RFC 4303 : IP Encapsulating Security Payload (ESP)<br /> * RFC 5095 : Deprecation of Type 0 Routing Headers in IPv6 Specification [http://www.bortzmeyer.org/5095.html Analyse]<br /> * RFC 7045 : Transmission and Processing of IPv6 Extension Headers [http://www.bortzmeyer.org/7045.html Analyse]<br /> * RFC 7872 : Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World [http://www.bortzmeyer.org/7872.html Analyse]<br /> * [http://livre.g6.asso.fr/index.php/S%C3%A9curit%C3%A9 Chapitre Sécurité du livre &quot;IPv6, Théorie et Pratique&quot;]</div> Ptournoux2 http://livre.g6.asso.fr/index.php?title=File:Moocipv6-act24-SRH-rsvp.png&diff=14916 File:Moocipv6-act24-SRH-rsvp.png 2017-04-24T10:25:20Z <p>Ptournoux2: Exemple d'utilisation de RSVP-TE avec MPLS en vue d'introduire le Segment Routing.</p> <hr /> <div>Exemple d'utilisation de RSVP-TE avec MPLS en vue d'introduire le Segment Routing.</div> Ptournoux2 http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act24-s6&diff=14915 MOOC:Compagnon Act24-s6 2017-04-24T10:19:46Z <p>Ptournoux2: /* Segment Routing Header (SRH) */</p> <hr /> <div>__NOTOC__ <br /> =Activité 24 : Le mécanisme d’extension de l'en-tête IPv6=<br /> <br /> == Introduction ==<br /> <br /> 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 :<br /> * soit par le destinataire du paquet IPv6,<br /> * soit par les routeurs intermédiaires en charge de l’acheminement du paquet IPv6.<br /> <br /> De nombreuses extensions ont été définies, afin d'assurer des fonctions comme : <br /> * le routage par la source,<br /> * la gestion de la fragmentation,<br /> * la confidentialité des communications (mécanisme ''ipsec''),<br /> * etc. <br /> <br /> 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.<br /> <br /> == Principe des extensions IPv6==<br /> <br /> 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).<br /> Une extension a une longueur multiple de 8 octets (64 bits). Elle commence par un champ &lt;tt&gt;Next header&lt;/tt&gt; qui définit sur 1 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.<br /> <br /> 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.<br /> <br /> '''''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.''<br /> <br /> Une présentation illustrée des extensionsIPv6 peut être consultée sur le site de Cisco&lt;ref&gt;Cisco (2006) White paper.[http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html IPv6 Extension Headers Review and Considerations]&lt;/ref&gt;.<br /> <br /> == Le champ ''Next Header'' ==<br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_ipv6_header_next-header_v02.jpg|thumb|right|300px|Figure 1 : Localisation du champ &lt;tt&gt;Next Header&lt;/tt&gt; dans l'en-tête IPv6.]]<br /> &lt;/center&gt;<br /> Le champ &lt;tt&gt;Next Header&lt;/tt&gt; 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 :<br /> &lt;center&gt;{{MOOC_Valeurs_du_champ_en-tête_suivant}}<br /> &lt;/center&gt;<br /> <br /> == Intégration des extensions d’en-tête dans le paquet IPv6==<br /> 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: <br /> * extensions impliquant tous les routeurs intermédiaires : ''Hop-by-Hop'' ;<br /> * extensions impliquant seulement certains routeurs désignés : ''Routing'' ;<br /> * extension impliquant le destinataire : ''Authentication'', ''Encapsulating Security Payload'', Fragmentation, Destination.<br /> <br /> <br /> 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 &lt;tt&gt;en-tête suivant&lt;/tt&gt; et un champ &lt;tt&gt;longueur&lt;/tt&gt;. Le premier paquet ne contient pas d'extension ; le champ &lt;tt&gt;en-tête suivant&lt;/tt&gt; pointe sur ICMPv6. Le second paquet ne contient pas d'extension ; le champ &lt;tt&gt;en-tête suivant&lt;/tt&gt; 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. <br /> * 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.<br /> * 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. <br /> * Les extensions peuvent être vues comme un protocole 3.5 (entre la couche 3 et la couche 4). En effet, à part l'extension de &quot;proche en proche&quot;, 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 &lt;tt&gt;adresse de destination&lt;/tt&gt; du paquet IPv6). <br /> <br /> &lt;center&gt;<br /> [[image:2015_10_10_extensions_IPv6_v01.jpg|thumb|center|600px|Figure 2 : Enchaînement d'extensions.]]<br /> &lt;/center&gt;<br /> <br /> == Quelques exemples ==<br /> <br /> === Fragmentation ===<br /> La fragmentation, telle qu'elle est pratiquée dans IPv4, n'est pas très performante. Initialement, elle servait à rendre transparente les limitations physiques des supports de transmission. Dans IPv4, quand un routeur ne peut pas transmettre un paquet à cause de sa trop grande taille, et si le bit DF ''don't fragment'' est à 0, il découpe l'information à transmettre en fragments. Or, le réseau IP étant un réseau à datagrammes, il n'y a pas de possibilité de contrôler les fragments. Deux fragments successifs peuvent prendre deux chemins différents et, par conséquent, seul le destinataire peut effectuer le ré-assemblage. En conséquence, après la traversée d'un lien impliquant une fragmentation, le reste du réseau ne voit passer que des paquets de taille réduite. <br /> <br /> 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 1981 : Mécanisme de découverte du PMTU). En pratique, une taille de paquets de 1 500 octets est presque universelle.<br /> <br /> Il existe pourtant des cas où la fragmentation est nécessaire. Ainsi, une application telle que NFS sur UDP suppose que la fragmentation existe et produit des messages de taille quelconque. Comme on ne veut pas modifier ces applications, la couche réseau d'IPv6 doit aussi être capable de gérer la fragmentation. Pour réduire le travail des routeurs intermédiaires, la fragmentation se fera au niveau de la source et le ré-assemblage par le destinataire. Les informations utiles pour ces mécanismes (identification du paquet fragmenté, place du fragment) sont transportées dans une extension de fragmentation, représentée dans la figure 3. <br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_PMTU_5_v01.jpg|thumb|center|600px|Figure 3 : Format de l'extension de fragmentation.]]<br /> &lt;/center&gt;<br /> <br /> * Le champ longueur de l'extension est remplacé par un champ réservé, positionné pour l'instant à 0. Un champ de longueur est, car l'extension tient sur un seul mot de 64 bits et le premier mot n'est pas compté dans le calcul de longueur des extensions.<br /> * Le &lt;tt&gt;fragment offset&lt;/tt&gt; indique, lors du ré-assemblage, la position à laquelle les données du fragment doivent s'insérer. Ceci permet de résoudre les problèmes dus au déséquencement éventuel des datagrammes. Ce champ étant sur 13 bits, la taille des fragments, excepté le dernier, doit être multiple de 8 octets (alignement sur frontière de mots de 64 bits),<br /> * Le bit &lt;tt&gt;M&lt;/tt&gt; (More data) est à 1 sur les fragments intermédiaires et à 0 sur le fragment final,<br /> * Le champ &lt;tt&gt;identification&lt;/tt&gt; permet de repérer les fragments appartenant à un même paquet initial pour une source et une destination données.<br /> <br /> Le bit DF (Don't Fragment), de l'en-tête IPv4 n'est plus nécessaire. Si un paquet est trop grand, il y aura rejet par le routeur et émission d'un message ICMP.<br /> <br /> Dans IPv6, 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 les autres extensions et l'en-tête de niveau 4 ne seront présents que dans le premier fragment.<br /> <br /> Le mécanisme de gestion de la taille d'un paquet IPv6, selon les différents cas possibles, est approfondi dans l'activité suivante.<br /> <br /> === Extensions d'authentification (AH) et de confidentialité (ESP) ===<br /> <br /> 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.<br /> <br /> 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. C'est-à-dire, si un code d'authentification de message &lt;ref&gt;Code d'authentification de message, [https://fr.wikipedia.org/wiki/Code_d%27authentification_de_message Article Wikipedia]&lt;/ref&gt; est utilisé, il lui suffit 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.<br /> <br /> 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.<br /> <br /> 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 algorithme(s) de chiffrement, la ou les clé(s), et un indice de paramètres de sécurité.<br /> <br /> === Segment Routing Header (SRH) ===<br /> <br /> Cette extension est une des briques qui permet la mise en oeuvre de l'ingénierie de traffic et de la qualité de sevice 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 necessiter que le délai de bout en bout reste inférieur à 100ms, que le débit disponible soit au minimum de 2mbit/s et que le taux de perte reste inférieur à 1%. La solution habituellement mise en oeuvre pour le respect de ces métriques de qualité de service est RSVP-TE [Pujolle Les Réseaux 2014]. RSVP est un protocol de reservation de ressource sur les routeurs du chemin entre une source et une destination. La composante d'ingenerie de traffic permet notamment de choisir explicitement le chemin qui sera suivit par le paquet. Lorsqu'une appication aura besoin de reserver des ressources, un circuit MPLS sera établi et le protocole RSVP reservera les ressources sur l'ensemble des routeurs qui composent le chemin. La figure X résume ce comportement, le noeud A est la source du flot de vidéo conférence destiné à B, elle demande l'installation d'un chemin via MPLS. Le controleur determine 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 doivent accepter la requête.<br /> <br /> FIGURE RSVP<br /> <br /> L'inconvénient de cette méthode est qu'avec RSVP, les reservations doivent être fréquement renouvellées et les routeurs doivent garder des états relatifs à chacun des flots. A 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 couteux en temps, en états, et en communication. Pour finir, si un des équipements 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 [http://www.segment-routing.net/tutorials/2017-03-06-segment-routing-traffic-engineering-srte/].<br /> <br /> Le concept de segment routing a été proposé pour palier à ces désavantages. Il permet de réduire l'intelligence des équipements du réseau. Un controleur choisi le chemin qui respecte les besoins de qualité de service du noeud. Le chemin à suivre ainsi que le traitement à associer aux paquets sont ensuite explicitement listés dans leurs entê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 à empreinter ou encore un service fournit par le routeur sur lequel transite le paquet. La séquence de segments que doit suivre le paquet peut être implémenté via une liste de label MPLS ou dans le cas d'en réseau IPv6 via l'option Segment Routing de l'entête [https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06]. Contrairement à MPLS, le segment routing avec IPv6 ne requière pas que tous les équipements traversés par le paquet soient compatibles avec cette option. Cela permet un déploiement progressif et de traverser plusieurs types de réseaux. Notons qu'il n'est pas necessaire d'inscrire l'integralité du chemin dans la liste. Les règles routage classique (IGP) s'appliquent pour acheminer le paquets entre les noeuds explicitement listés dans l'entête. Dans le cas de la figure 2, pour suivre le chemin G,H,I,K,N, il est seulement necessaire 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.a.d. B. Le paquet suit le plus court chemin entre I et B en l'occurence I,K,N. La taille de l'entête est donc limitée.<br /> <br /> <br /> <br /> Le projet de RFC [https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06] prevoit qu'un segment soit représenté sur 128bit, c.a.d. autant qu'une adresse IPv6. Le nombre de segments inclus dans l'option SRH peut être déduit du champs Hdr Ext Len qui indique le nombre d'octets de l'option moins un. Le prochain segment à appliquer est indiqué par le champs Segments Left qui indique nombre de segments restant à appliquer au paquet. Le segment courant est inscrit dans le champs adresse de destination de l'entête IPv6. Lorsque le traitement associé à un segment est achevé, le prochain segment à traiter est copié dans le champs adresse de destination et le champs Segments Left est décrementé.<br /> <br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_IPv6_extension_routage_v02.jpg|thumb|center|400px|Figure 5 : Extension de routage par la source.]]<br /> &lt;/center&gt;<br /> <br /> L'option SRH est très proche de l'entête de routage défini dans la RFC2460 de IPv6. L'entête de routage devait notamment permettre le routage à la source qui conciste à lister les routeurs que devaient traverser le paquet au cours de son acheminement. Cette pratique a été dépréciée en 2007 par la RFC 5095 pour des raisons de sécurité. En effet cela permettait de generer de la congestion sur certains chemins, des attaques de déni de service, de contourner les règles de filtrages de certains parfeu ou encore d'atteindre des machines publiques accessibles (en DMZ) pour acceder à des machines qui ne sont pas directement accessibles. [A completer: http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf].<br /> <br /> Pour être accepté, l'option SRH devait donc garantir qu'elle ne serait pas vulnérable à ces attaques. Plusieurs cas d'utilisation sont décrits. Lorsque la SRH est générée au sein du réseau de l'opérateur (e.g. routeur de bordure) les attaques listées dans la RFC5095 sont innopérantes. Les routeurs de bordures doivent simplement filtrer les paquets venus de l'exterieur pour éviter de hôtes s'attribuent des privilèges ou provoque de la congestion sur certains lien. Lorsque les SRH sont générées en dehors du réseau de l'opérateur, la projet de RFC prévoit l'utilisation d'un mécanisme d'autentification de l'entête [RFC2104] (option HMAC). La clé de chiffrement de l'entête HMAC est distribuée au sein des noeuds autorisés à générer ou manipuler des entêtes SRH.<br /> <br /> <br /> <br /> ----------------------<br /> <br /> Cette extension permet d'imposer à un paquet une route différente de celle offerte par les politiques de routage présentes sur le réseau (cf. Figure 4). Pour l'instant, seul le routage par la source (&lt;tt&gt;type&lt;/tt&gt; = 0), similaire à l'option ''Loose Source Routing'' d'IPv4, est défini pour IPv6. La mobilité IPv6 a également introduit une autre extension de routage (&lt;tt&gt;type&lt;/tt&gt; = 2, optimisation dans le cas du mobile dans un réseau étranger).<br /> &lt;center&gt;<br /> [[image:2015_10_14_IPv6_extension_routage_v00.jpg|thumb|center|400px|Figure 4 : Routage par la source.]]<br /> &lt;/center&gt;<br /> Dans IPv4, le routage peut être strict (le routeur suivant, présent dans la liste, doit être un voisin directement accessible) ou libéral ''loose'' (un routeur peut utiliser les tables de routage pour joindre le routeur suivant, servant de relais). Dans IPv6, seul le routage libéral est autorisé. En effet, le routage strict était initialement mis en place surtout pour des raisons de sécurité. La source devait être absolument sûre du chemin pris par les paquets. Cette utilisation a maintenant disparu du réseau. <br /> <br /> Le principe du routage par la source, ou ''Source Routing'', dans IPv4, qui vient d’être rappelé, est le même pour IPv6. L'émetteur met, dans le champ &lt;tt&gt;destination&lt;/tt&gt; du paquet IPv6, l'adresse du premier routeur servant de relais. L'extension contient la suite de la liste des autres routeurs relais et le destinataire. Quand un routeur reçoit un paquet qui lui est adressé, comportant une extension de routage par la source, il permute son adresse avec l'adresse du prochain routeur et réémet le paquet vers cette adresse suivante.<br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_IPv6_extension_routage_v02.jpg|thumb|center|400px|Figure 5 : Extension de routage par la source.]]<br /> &lt;/center&gt;<br /> <br /> La figure 5 donne le format de l'extension de routage par la source : <br /> * Le champ de longueur &lt;tt&gt;Hdr Ext Len&lt;/tt&gt; de l'en-tête indique le nombre de mots de 64 bits qui composent l'extension. Pour l'extension de &lt;tt&gt;type&lt;/tt&gt; 0, cela correspond au nombre d'adresses présentes dans la liste, multiplié par 2. <br /> * Le champ &lt;tt&gt;Routing Type&lt;/tt&gt; indique la nature du routage. Pour l'instant, seul le routage par la source, de &lt;tt&gt;type&lt;/tt&gt; 0 est spécifié. La suite de l'en-tête correspond à ce &lt;tt&gt;type&lt;/tt&gt;. <br /> * Le champs &lt;tt&gt;Segment Left&lt;/tt&gt; est décrémenté après la traversée d'un routeur. Il indique le nombre d'équipements qui doivent encore être traversés. Il permet de trouver l'adresse qui devra être substituée. <br /> * Les 32 bits suivants sont inutilisés pour préserver l'alignement. <br /> * La liste, comprenant les routeurs à traverser et le destinataire, est fournie. Ces adresses ne peuvent pas être de type multicast.<br /> <br /> À noter : il n'y a pas de champ &lt;tt&gt;NH&lt;/tt&gt; dans TCP.<br /> <br /> Dans la figure 6, nous pouvons suivre l’évolution des changements des champs pendant la traversée du réseau du paquet IPv6 :<br /> * Noter l’évolution du champ &lt;tt&gt;Segment Left&lt;/tt&gt; qui pointe vers l’adresse du prochain routeur spécifié apte à traiter l’extension RH0.<br /> * Chaque routeur spécifié successif remplace l’adresse destination du datagramme avec l’adresse pointée par le champ &lt;tt&gt;Segment Left&lt;/tt&gt;. Une fois que le pointeur est décrémenté à 0, plus aucun changement ne sera effectué.<br /> * Les routeurs non spécifiés relaient les paquets de manière transparente.<br /> <br /> &lt;center&gt;<br /> [[image:2015_10_14_IPv6_extension_RH0_04.jpg|thumb|center|665px|Figure 6 : Extension de routage.]]<br /> &lt;/center&gt;<br /> <br /> == Conclusion ==<br /> 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 communications 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.<br /> <br /> 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 pris en compte dans le traitement des paquets, notamment le filtrage sur les valeurs du champ ''Next Header'' de l'en-tête IPv6.<br /> <br /> == Références bibliographiques ==<br /> &lt;references /&gt;<br /> <br /> == Pour aller plus loin==<br /> Vous pouvez approfondir vos connaissances en consultant les documents de ce paragraphe.<br /> RFC et leur analyse par S. Bortzmeyer :<br /> * RFC 1981 : Path MTU Discovery for IP version 6<br /> * RFC 2460 : Internet Protocol, Version 6 (IPv6) Specification [http://www.bortzmeyer.org/2460.html Analyse]<br /> * RFC 4302 : IP Authentication Header<br /> * RFC 4303 : IP Encapsulating Security Payload (ESP)<br /> * RFC 5095 : Deprecation of Type 0 Routing Headers in IPv6 Specification [http://www.bortzmeyer.org/5095.html Analyse]<br /> * RFC 7045 : Transmission and Processing of IPv6 Extension Headers [http://www.bortzmeyer.org/7045.html Analyse]<br /> * RFC 7872 : Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World [http://www.bortzmeyer.org/7872.html Analyse]<br /> * [http://livre.g6.asso.fr/index.php/S%C3%A9curit%C3%A9 Chapitre Sécurité du livre &quot;IPv6, Théorie et Pratique&quot;]</div> Ptournoux2