Difference between revisions of "MOOC:Compagnon Act24-s6"
From Livre IPv6
(→Justification des extentions) |
|||
| Line 1: | Line 1: | ||
= Justification des extentions = | = Justification des extentions = | ||
| + | |||
| + | Le besoin d’étendre l’en-tête IPv6 permet d’ajouter des fonctionnalités supplémentaires impliquant : | ||
| + | * Soit le destinataire du paquet IPv6 | ||
| + | * Soit des routeurs intermédiaires étant impliqués dans l’acheminement de ce paquet IPv6 | ||
| + | De nombreuses extensions ont été définies, nous allons proposer quelques exemples simples et démonstratifs de ce mécanisme. | ||
| + | |||
| + | [[image:2015_10_14_ipv6_header_next-header_v02.jpg|thumb|center|600px|champ Next Header]] | ||
[[image:Ipv6_ext_header_02.jpg|thumb|left|500px|Figure 4-5 ''Enchaînement d'extensions"'']] | [[image:Ipv6_ext_header_02.jpg|thumb|left|500px|Figure 4-5 ''Enchaînement d'extensions"'']] | ||
Revision as of 13:39, 14 October 2015
Contents
Justification des extentions
Le besoin d’étendre l’en-tête IPv6 permet d’ajouter des fonctionnalités supplémentaires impliquant :
- Soit le destinataire du paquet IPv6
- Soit des routeurs intermédiaires étant impliqués dans l’acheminement de ce paquet IPv6
De nombreuses extensions ont été définies, nous allons proposer quelques exemples simples et démonstratifs de ce mécanisme.
La figure "Enchaînement d'extensions" montre la souplesse avec laquelle plusieurs extensions peuvent être chaînées. Chaque extension contient dans son en-tête un champ en-tête suivant et longueur. Le premier paquet ne contient pas d'extension, le champ en-tête suivant pointe sur ICMPv6. Le second paquet ne contient pas d'extension, le champ en-tête suivant pointe sur TCP. Le troisième paquet contient une extension de protection qui pointe sur UDP. Dans le dernier paquet, une extension de routage, qui pointe sur une extension de fragmentation, qui finalement pointe sur ICMPv6.
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 au l'identificateur de flux qui permettait de refléter au niveau 3 un flux particulier et évitait de dérouler l'enchaînement. Bien entendu, les pare-feux devront vérifier les numéros de ports.
Les extensions peuvent être vues comme un protocole 3.5 (entre la couche 3 et la couche 4). En effet, à part l'extension de proche-en-proche, qui est traitée par tous les routeurs traversés, les autres extensions ne sont traitées que par le destinataire du paquet (i.e. celui spécifié dans le champ adresse de destination du paquet IPv6).
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.
- En-tête suivant
- Ce champ a une fonction similaire au champ protocole du paquet IPv4. Il identifie le prochain en-tête. Il peut s'agir d'un protocole (de niveau supérieur ICMP, UDP, TCP...) ou de la désignation d'extensions (cf. tableau Valeurs du champ en-tête suivant).
| valeur | Extension | valeur | Protocole | ||
|---|---|---|---|---|---|
| 0 | Proche-en-proche | 4 | IPv4 | ||
| 43 | Routage | 6 | TCP | ||
| 44 | Fragmentation | 17 | UDP | ||
| 50 | Confidentialité | 41 | IPv6 | ||
| 51 | Authentification | 58 | ICMPv6 | ||
| 59 | Fin des en-têtes | 132 | SCTP | ||
| 60 | Destination | 136 | UDP-lite | ||
| 135 | Mobilité | ||||
| 140 | Shim6 |
Proche-en-proche
Cette extension (en anglais : hop-by-hop) se situe toujours en première position et est traitée par tous les routeurs que le paquet traverse. Le type associé (contenu dans le champ d'en-tête en-tête suivant de l'en-tête précédent) est 0 et le champ longueur de l'extension contient le nombre de mots de 64 bits moins 1.
L'extension est composée d'options. Pour l'instant, seules quatre options, dont deux de bourrage, sont définies (cf. Format des options IPv6). Chaque option est une suite d'octets. Le premier octet est un type, le deuxième (sauf pour l'option 0) contient la longueur de l'option moins 2. Les deux premiers bits de poids fort du type définissent le comportement du routeur quand il rencontre une option inconnue :
- 00 : le routeur ignore l'option ;
- 01 : le routeur rejette le paquet ;
- 10 : le routeur rejette le paquet et retourne un message ICMPv6 d'inaccessibilité ;
- 11 : le routeur rejette le paquet et retourne un message ICMPv6 d'inaccessibilité si l'adresse de destination n'est pas multicast.
Le bit suivant du type indique que le routeur peut modifier le contenu du champ option (valeur à 1) ou non (valeur à 0).
Les quatre options de proche-en-proche sont :
- Pad1 (type 0). Cette option est utilisée pour introduire un octet de bourrage.
- Padn (type 1). Cette option est utilisée pour introduire plus de 2 octets de bourrage. Le champ longueur indique le nombre d'octets qui suivent.
Les options de bourrage peuvent sembler inutiles avec IPv6 puisqu'un champ longueur pourrait en donner la longueur exacte. En fait les options de bourrage servent à optimiser le traitement des paquets en alignant les champs sur des mots de 32, voire 64 bits ; le RFC 2460 discute en annexe de la manière d'optimiser le traitement tout en minimisant la place prise par les options.
- Jumbogramme (type 194 ou 0xc2, RFC 2675). Cette option est utilisée quand le champ longueur des données du paquet IPv6 n'est pas suffisant pour coder la taille du paquet. Cette option est essentiellement prévue pour la transmission à grand débit entre deux équipements. Si l'option jumbogramme est utilisée, le champ longueur des données utiles dans l'en-tête IPv6 vaut 0.
Noter que le type commence par la séquence binaire 11, ce qui permet au routeur ne traitant pas les jumbogrammes d'en informer la source. Celle-ci pourra réémettre l'information sans utiliser cette option.
- L'option Router Alert (RFC 2711) demande à un routeur d'examiner le contenu des données qu'il relaie (Router Alert existe également en IPv4, RFC 2113). En principe, le processus de relayage (recopier le paquet sur une interface de sortie en fonction de l'adresse destination et des tables de routage) doit être le plus rapide possible. Mais pour des protocoles comme la gestion des groupes de multicast avec MLD (Multicast Listener Discovery) ou la signalisation des flux avec RSVP, tous les routeurs intermédiaires doivent tenir compte des données.
L'émetteur envoie les données à la destination, mais s'il précise l'option Router Alert, les routeurs intermédiaires vont analyser les données, voire modifier leur contenu avant de relayer le paquet. Ce mécanisme est efficace puisque les routeurs n'ont pas à analyser le contenu de tous les paquets d'un flux.
Le type de l'option vaut 5. Il commence par la séquence binaire 00, puisqu'un routeur qui ne connaît pas cette option doit relayer le paquet sans le modifier. Le champ valeur de l'option contient :- 0 : pour les messages du protocole MLD de gestion des groupes multicast ;
- 1 : pour les messages RSVP ;
- 2 : pour les réseaux actifs ;
- les autres valeurs sont réservées.
Destination
Cette extension, dont le format est identique à l'extension de proche-en-proche (cf. figure Format des extensions "proche-en-proche" et "destination"), contient des options qui sont traitées par l'équipement destinataire. Pour l'instant, à part les options de bourrage (voir Pad1 et Padn) et de mobilité (cf. Mobilité dans IPv6), la seule autre option concerne le tunnelage dans des paquets IPv6 (RFC 2473). Cette option permet de limiter le niveau d'encapsulation dans des tunnels des paquets IPv6.
Routage
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. Pour l'instant seul le routage par la source (type = 0), similaire à l'option Loose Source Routing d'IPv4, est défini pour IPv6. La mobilité IPv6 a également introduit une extension de routage (type = 2) (cf. Optimisation dans le cas du mobile dans un réseau étranger).
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.
Le principe du routage par la source ou Source Routing dans IPv4 est rappelé en introduction de ce chapitre sur les extensions. Le principe est le même pour IPv6. L'émetteur met dans le champ destination 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.
La figure Format de l'extension routage par la source donne le format de l'extension de routage par la source :
- Le champ longueur de l'en-tête indique le nombre de mots de 64 bits qui composent l'extension. Pour l'extension de type 0, cela correspond au nombre d'adresses présentes dans la liste, multiplié par 2.
- Le champ type indique la nature du routage. Pour l'instant, seul le routage par la source, de type 0 est spécifié. La suite de l'en-tête correspond à ce type.
- Le nombre de segments restant 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.
- Les 32 bits suivants sont inutilisés pour préserver l'alignement.
La liste comprenant les routeurs à traverser et le destinataire est fournie. Ces adresses ne peuvent pas être multicast.
Fragmentation
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 à datagramme, 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.
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 Mécanisme de découverte du PMTU (RFC 1981)). En pratique une taille de paquets de 1 500 octets est presque universelle.
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 grande taille. 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 chez l'émetteur et le réassemblage chez le récepteur.
Le format de l'extension de fragmentation est donné figure Format de l'extension de fragmentation. La signification des champs est identique à celle d'IPv4 :
- Le champ place du fragment indique lors du réassemblage où les données doivent être insérées. Ceci permet de parer les problèmes dus au déséquencement dans les réseaux orientés datagrammes. Comme ce champ est sur 13 bits, la taille de tous les segments, sauf du dernier, doit être multiple de 8 octets.
- Le bit M s'il vaut 1 indique qu'il y aura d'autres fragments émis.
- Le champ identification permet de repérer les fragments appartenant à un même paquet initial. Il est différent pour chaque paquet et recopié dans ses fragments.
- Le bit DF (don't fragment) n'est plus nécessaire puisque, si un paquet est trop grand, il y aura rejet du paquet par le routeur.
Dans IPv4, la valeur d'une option était codée de manière à indiquer au routeur effectuant la fragmentation si elle devait être copiée dans les fragments. Dans IPv6, l'en-tête et les extensions qui concernent les routeurs intermédiaires (pour l'instant proche-en-proche, routage par la source) sont recopiées dans chaque fragment.
![]()
Extension d'authentification AH
Table des matières
Gestion des associations et des clés
![]()
L'extension ESP (Encapsulating Security Payload) décrite dans le RFC 2406 permet de chiffrer l'ensemble des paquets ou leur partie transport et de garantir l'authentification et l'intégrité de ces paquets. Cette extension permet optionnellement de détecter les rejeux (à condition que le service d'authentification soit assuré) et garantit de façon limitée la confidentialité du flux.
Pour obtenir ces services de sécurité, il est nécessaire, avant d'émettre un paquet IP sur le réseau, de chiffrer les données à protéger, de calculer un authentificateur et d'encapsuler ces informations dans l'en-tête de confidentialité. Cela nécessite bien entendu l'existence d'une association de sécurité précisant entre autres le(s) algorithme(s) de chiffrement, la (les) clé(s) et un indice de paramètres de sécurité.
Deux modes de protection
L'extension ESP est composée d'un en-tête ESP, d'une queue ESP et d'un authentificateur ESP. Suivant le mode de protection sélectionné, l'étendue des champs protégés diffère :
- En mode transport, seules les données de niveau transport du paquet IP (de type TCP, UDP, ICMP) sont protégées. Plus précisément, le chiffrement porte sur les données et sur la queue ESP avec la possibilité de porter sur l'extension destination à condition que celle-ci soit placée dans l'extension ESP (cf. figure Positionnement de l'extension ESP en modes transport et tunnel). La protection en intégrité/authentification porte sur toute l'extension ESP excepté l'authentificateur placé dans le champ authentificateur. Elle assure ainsi la protection des données de niveau transport du paquet IP. L'extension ESP est insérée dans le paquet IP juste après l'en-tête du paquet IP et les extensions avec la possibilité d'avoir l'extension destination placée juste avant l'extension ESP ou encapsulée dans l'extension ESP en première position.
- En mode tunnel, la protection porte sur tout le paquet IP original. C'est-à-dire, le paquet IP original est chiffré avant d'être encapsulé dans l'extension ESP. Cette extension est alors placée dans un nouveau paquet IP dont les en-têtes IP sont en clair (non chiffrés) pour permettre au réseau IP de correctement acheminer le paquet (cf. figure Positionnement de l'extension ESP en modes transport et tunnel). Il s'agit du classique chiffrement des artères. La protection en intégrité/authentification porte sur l'extension ESP (comprenant le paquet IP original) excepté l'authentificateur ESP. L'extension ESP rend le service de confidentialité du flux de façon limitée en ce sens que ce service n'est rendu qu'en mode tunnel et ne porte que sur la confidentialité des adresses IP. En effet, l'extension ESP en mode tunnel réalise le chiffrement de l'intégralité des paquets IP originaux, y compris leurs adresses IP. De ce fait, si les équipements qui mettent en oeuvre IPsec ne sont pas l'émetteur et le destinataire final des paquets, leurs adresses masqueront celles de ces derniers. Un intrus placé en écoute sur le réseau au niveau d'un tunnel IP (entre les passerelles de sécurité) ne pourra pas dans ce cas là connaître les adresses des stations en communication.
Contenu de l'extension ESP
L'extension ESP est composée des champs suivants (cf. figure Format de l'extension d'ESP) :
- Le champ indice de paramètres de sécurité (SPI) combiné à l'adresse du (des) destinataire(s), identifie l'association de sécurité utilisée pour construire cette extension.
- Le numéro de séquence permet de détecter les rejeux de paquet IP.
- Le champ charge utile peut contenir soit un paquet IP complet (en-tête IP + extensions + données de niveau transport), soit l'extension destination suivie de données de niveau transport, soit des données de niveau transport uniquement.
- Ce champ peut également contenir des données de synchronisation selon les algorithmes de chiffrement utilisés.
- Le champ bourrage permet d'ajouter des bits de bourrage pour aligner les données à chiffrer sur un nombre d'octets dépendant de l'algorithme de chiffrement utilisé. Le champ bourrage est optionnel. Sa présence est précisée par l'association de sécurité utilisée.
- Le champ longueur du bourrage indique la longueur en octets du champ bourrage.
- Le champ en-tête suivant identifie le type de données contenues dans le premier champ du champ charge utile.
- Le champ authentificateur est optionnel et sa présence dépend de l'association de sécurité utilisée (SPI + adresse(s) de destination + ESP). Il est calculé à l'aide de l'algorithme et de la clé correspondant à l'association de sécurité.
Notez que le champ en-tête ESP inclut l'indice des paramètres de sécurité et le numéro de séquence, tandis que le champ queue ESP comprend les champs bourrage, longueur du bourrage et en-tête suivant.
La détection de rejeu est optionnelle car lors de la génération d'une extension ESP, il est nécessaire de préciser un numéro de séquence adéquat dans le champ numéro de séquence tandis qu'à l'extraction de l'extension ESP, la vérification du numéro de séquence n'est pas obligatoire.
Le RFC 2406 précise les algorithmes de chiffrement que doivent obligatoirement implémenter les équipements IPsec pour rendre le service de confidentialité. Si dans le RFC 2406, seul l'algorithme DES dans le mode d'utilisation CBC (Cipher Block Chaining) est mentionné obligatoire, au fil du temps, l'IETF a fait évoluer la liste en ajoutant en 1999 le triple DES et plus récemment l'AES (Advanced Encryption Stantard). Quant à la génération de l'authentificateur, les mêmes mécanismes que pour l'extension AH sont préconisés par défaut, à savoir HMAC- MD5, HMAC-SHA-1.
Le chiffrement des données dans l'extension ESP n'est pas obligatoire. Dans ce cas, seuls les services d'intégrité/authentification sont rendus, mais ils ne portent que sur l'extension ESP, contrairement à l'extension AH qui porte sur tout le paquet IP excepté certains champs "modifiables" par le réseau. Dans certains cas, suivant le niveau de protection en intégrité souhaité, il peut être nécessaire d'utiliser les deux extensions AH et ESP dans le même paquet, l'extension ESP ne rendant alors que le service de confidentialité.
L'extension ESP souffre tout comme l'extension AH d'incompatibilités avec le mécanisme de traduction d'adresse, et ce, bien que l'authentification réalisée ne porte que sur le contenu de l'en-tête ESP ; cependant contrairement à AH, il existe une solution palliative présentée ci-dessous. Le problème d'incompatibilité de ESP en mode transport avec la traduction d'adresses seules est lié aux protocoles TCP et UDP qui définissent un champ de contrôle dont le calcul fait intervenir les adresses IP ; ainsi la modification d'une adresse suppose la modification de ce contrôle, ce qui n'est pas réalisable avec ESP en mode transport ; en effet, soit le chiffrement est activé dans ESP et le champ de contrôle est inaccessible car chiffré ; soit les services d'authentification/intégrité sont activés, et la modification du champ de contrôle conduira à la détection d'un problème d'intégrité du paquet et au rejet du paquet par l'équipement IPsec récepteur.
Le fait de traduire en plus des adresses les numéros de port ajoute encore davantage d'incompatibilités. Pour ESP, c'est l'encapsulation elle-même qui pose problème car elle rend les numéros de port soit inaccessibles (chiffrement activé), soit interdits de modification (car protégés en intégrité). Enfin, noter que pour ESP en mode tunnel, les numéros de port sont inexistants.
Une solution est aujourd'hui définie pour pallier à cette incompatibilité. Elle consiste à n'utiliser que le protocole ESP (mode transport ou tunnel) et à réaliser une encapsulation UDP supplémentaire. Plus précisément, un tunnel UDP doit être établi entre les deux équipements IPsec ; les données encapsulées dans ce tunnel sont protégées par le protocole ESP. Ainsi, la traduction des adresses/numéros de port donne lieu à la modification du champ de contrôle de UDP sans porter atteinte à l'intégrité de l'en-tête ESP et la traduction de numéros de port est faite sur les numéros de port UDP qui sont accessibles ici. Afin de détecter la traversée d'un équipement de traduction d'adresse et n'activer l'encapsulation UDP que lorsque nécessaire, les passerelles IPsec peuvent faire appel au mécanisme de NAT-traversal [RFC 3947] [RFC 3948] lors de l'établissement dynamique d'une association de sécurité.
Évolutions prévues
La prochaine version de l'extension ESP intègre les mêmes évolutions que AH concernant l'identification des associations de sécurité et les numéros de séquence. Tout comme pour AH, il est prévu que la liste des algorithmes obligatoires soit précisée dans un document indépendant et tenu à jour.
Il est également prévu de permettre l'usage d'un plus grand nombre d'algorithmes, comme les algorithmes dits "combinés" qui permettent simultanément de chiffrer et de protéger en intégrité. Ces algorithmes combinés nécessitent un aménagement du format de ESP. En effet, certains d'entre eux n'assurent l'intégrité que sur les données chiffrées ; d'autres peuvent étendre la protection en intégrité sur des champs extérieurs. Compte tenu que l'indice de paramètres de sécurité et le numéro de séquence ne sont pas chiffrés mais nécessitent d'être protégés en intégrité, il peut être nécessaire de les faire apparaître deux fois dans le paquet : dans l'en-tête ESP et dans la charge utile. De façon à rendre l'extension ESP ouverte à un grand nombre d'algorithmes, le champ authentificateur n'est plus tenu de tenir sur un nombre entier de 32 mots.
Afin de se prémunir des analyses statistiques portant sur les flots de données chiffrés, la prochaine version de la RFC 2406 prévoit d'assurer le service de confidentialité du flux. La technique utilisée consiste à introduire des données de bourrage (sans signification) dans les paquets IP. À cette fin, un nouveau champ optionnel - Traffic Flow Confidentiality - est défini et se trouve positionner dans la charge utile.
Enfin, trois configurations de ESP sont distinguées suivant que sont rendus le service d'intégrité seul, le service de confidentialité seul ou simultanément les services d'intégrité et de confidentialité. Cette distinction permet d'optimiser le traitement des paquets, et de permettre l'usage d'algorithmes combinés. Noter que le service de confidentialité est optionnel et peut donc ne pas être implémenté dans ESP.
![]()
Extension d'authentification AH
Table des matières
Gestion des associations et des clés
![]()
![]()
Déplacements des mobiles
Table des matières
Les risques induits par la mobilité et leur limitation
![]()
Format général du paquet
Nous avons vu que les en-têtes de mobilité sont utilisés pour transporter la signalisation de la gestion des associations de mobilité entre le noeud mobile, son agent mère et le noeud correspondant.
Un en-tête de mobilité ne doit jamais être utilisé en même temps qu'un en-tête de routage de type 2, excepté dans le seul cas du transport d'un acquittement d'une demande de BU. Il ne doit jamais non plus être utilisé en même temps qu'une extension de destination, sauf dans certains cas de Binding Update avec l'agent mère ainsi qu'avec des noeuds correspondants déjà identifiés.
Le format général d'un en-tête de mobilité est donné figure Format de l'extension de mobilité :
- Le champ en-tête suivant est pris dans le même espace de numérotation que les en-têtes d'extension d'IPv6 (cf. Valeurs du champ en-tête suivant). Dans le cas de la signalisation de mobilité, il doit valoir 59 (pas d'en-tête suivant).
- Le champ longueur de l'en-tête, en octets, ne prend pas en compte les 8 premiers octets de l'en-tête.
- Le champ type d'en-tête décrit les messages de signalisation donné au tableau Type des en-têtes de mobilité.
Type des en-têtes de mobilité
0
Demande de rafraîchissement émise par le noeud correspondant
1
Initialisation de test d'adresse mère (HoTI)
2
Initialisation de test d'adresse temporaire (CoTI)
3
Test d'adresse mère (HoT)
4
Test d'adresse temporaire (CoT)
5
Mise à jour d'association (émise depuis le noeud mobile)
6
Acquittement de mise à jour d'association
7
Erreur de mise à jour d'association
La structure et la longueur du message varient en fonction du numéro de l'en-tête. De plus, MIPv6 définit également des options de mobilité associées à ces messages. Comme la longueur des messages associés à chaque numéro d'en-tête est connue, la présence d'une option est déduite d'une longueur de l'en-tête plus grande que ce qui est suffisant pour le message. Elle se trouve forcément à la suite du message.
Comme toutes les en-tête IPv6, ces en-têtes de mobilité doivent être alignés sur des frontières de 8 octets. Des champs réservés seront éventuellement insérés pour respecter cette contrainte. Un noeud ne sachant pas interpréter une option doit l'ignorer. Actuellement MIPv6 ne définit d'option que pour les messages de BU (type 5) et leur acquittement (type 6).
Format des messages et options des différents types d'en-têtes
La demande de rafraîchissement d'association ne requiert aucune information spécifique. Le message est vide, il n'y a pas d'option. (cf. figure Format de l'extension de mobilité rafraîchissement d'association).
Les messages HoTI, CoTI ne contiennent que le nombre aléatoire émis par le noeud mobile. Il ne contient pas d'option. (cf. figure Format de l'extension de mobilité HoTI ou CoTI).
Les messages HoT, CoT contiennent, l'index du nombre aléatoire (nonce) choisi par le noeud correspondant, le nombre aléatoire émis par le noeud mobile (cookie), (pour le test home address ou care-of address) et le jeton chiffré (keygen token) émis par le noeud correspondant. Il ne contient pas d'option (cf. figure Format de l'extension de mobilité HoT ou CoT).
Les messages de notification de mise à jour d'association, émis par le noeud mobile, peuvent contenir des options mobiles. Si elles ne sont pas présentes, le paquet doit se terminer par 4 octets de bourrage. (cf. figure Format de l'extension de mobilité mise à jour d'association)
Les options possibles sont :
- Les données d'autorisation de mise à jour d'association. L'option est obligatoire pour les mises à jour émises vers le noeud correspondant puisqu'elles ne sont pas protégées par IPsec.
- L'indice du "nonce" choisi par le noeud correspondant.
- Une "care-of address" alternative.
Les message d'acquittement de mise à jour d'association peut contenir des options mobiles. Si elles ne sont pas présentes, le paquet doit être terminé par 4 octets de bourrage. (cf. figure Format de l'extension de mobilité acquittement de mise à jour d'association) :
- Une valeur du champ statut inférieure à 128 indique un acquittement, et une valeur supérieure un rejet. Le motif du rejet est codé par la valeur du statut.
- Le bit K = 1 indique que l'association de sécurité IPsec suivra les mouvements du noeud mobile. Le noeud correspondant doit le positionner à 0.
- Les options possibles sont :
- Les données d'autorisation de mise à jour d'association.
- Les informations de fréquence de rafraîchissement des associations.
Les messages d'erreur de mise à jour d'association contiennent un statut sur 8 bits codant l'erreur, ainsi que la home address de la mise à jour en erreur pour le cas où le noeud mobile aurait établi plusieurs associations avec le noeud correspondant (cf. figure Format de l'extension de mobilité message d'erreur).
![]()
Déplacements des mobiles
Table des matières
Les risques induits par la mobilité et leur limitation
![]()
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. Pour l'instant seul le routage par la source (type = 0), similaire à l'option Loose Source Routing d'IPv4, est défini pour IPv6. La mobilité IPv6 a également introduit une extension de routage (type = 2) (cf. Optimisation dans le cas du mobile dans un réseau étranger).
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.
Le principe du routage par la source ou Source Routing dans IPv4 est rappelé en introduction de ce chapitre sur les extensions. Le principe est le même pour IPv6. L'émetteur met dans le champ destination 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.
La figure Format de l'extension routage par la source donne le format de l'extension de routage par la source :
- Le champ longueur de l'en-tête indique le nombre de mots de 64 bits qui composent l'extension. Pour l'extension de type 0, cela correspond au nombre d'adresses présentes dans la liste, multiplié par 2.
- Le champ type indique la nature du routage. Pour l'instant, seul le routage par la source, de type 0 est spécifié. La suite de l'en-tête correspond à ce type.
- Le nombre de segments restant 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.
- Les 32 bits suivants sont inutilisés pour préserver l'alignement.
La liste comprenant les routeurs à traverser et le destinataire est fournie. Ces adresses ne peuvent pas être multicast.
Fragmentation
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 à datagramme, 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.
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 Mécanisme de découverte du PMTU (RFC 1981)). En pratique une taille de paquets de 1 500 octets est presque universelle.
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 grande taille. 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 chez l'émetteur et le réassemblage chez le récepteur.
Le format de l'extension de fragmentation est donné figure Format de l'extension de fragmentation. La signification des champs est identique à celle d'IPv4 :
- Le champ place du fragment indique lors du réassemblage où les données doivent être insérées. Ceci permet de parer les problèmes dus au déséquencement dans les réseaux orientés datagrammes. Comme ce champ est sur 13 bits, la taille de tous les segments, sauf du dernier, doit être multiple de 8 octets.
- Le bit M s'il vaut 1 indique qu'il y aura d'autres fragments émis.
- Le champ identification permet de repérer les fragments appartenant à un même paquet initial. Il est différent pour chaque paquet et recopié dans ses fragments.
- Le bit DF (don't fragment) n'est plus nécessaire puisque, si un paquet est trop grand, il y aura rejet du paquet par le routeur.
Dans IPv4, la valeur d'une option était codée de manière à indiquer au routeur effectuant la fragmentation si elle devait être copiée dans les fragments. Dans IPv6, l'en-tête et les extensions qui concernent les routeurs intermédiaires (pour l'instant proche-en-proche, routage par la source) sont recopiées dans chaque fragment.
| |
Extension d'authentification AH | Table des matières | Gestion des associations et des clés | |
L'extension ESP (Encapsulating Security Payload) décrite dans le RFC 2406 permet de chiffrer l'ensemble des paquets ou leur partie transport et de garantir l'authentification et l'intégrité de ces paquets. Cette extension permet optionnellement de détecter les rejeux (à condition que le service d'authentification soit assuré) et garantit de façon limitée la confidentialité du flux.
Pour obtenir ces services de sécurité, il est nécessaire, avant d'émettre un paquet IP sur le réseau, de chiffrer les données à protéger, de calculer un authentificateur et d'encapsuler ces informations dans l'en-tête de confidentialité. Cela nécessite bien entendu l'existence d'une association de sécurité précisant entre autres le(s) algorithme(s) de chiffrement, la (les) clé(s) et un indice de paramètres de sécurité.
Deux modes de protection
L'extension ESP est composée d'un en-tête ESP, d'une queue ESP et d'un authentificateur ESP. Suivant le mode de protection sélectionné, l'étendue des champs protégés diffère :
- En mode transport, seules les données de niveau transport du paquet IP (de type TCP, UDP, ICMP) sont protégées. Plus précisément, le chiffrement porte sur les données et sur la queue ESP avec la possibilité de porter sur l'extension destination à condition que celle-ci soit placée dans l'extension ESP (cf. figure Positionnement de l'extension ESP en modes transport et tunnel). La protection en intégrité/authentification porte sur toute l'extension ESP excepté l'authentificateur placé dans le champ authentificateur. Elle assure ainsi la protection des données de niveau transport du paquet IP. L'extension ESP est insérée dans le paquet IP juste après l'en-tête du paquet IP et les extensions avec la possibilité d'avoir l'extension destination placée juste avant l'extension ESP ou encapsulée dans l'extension ESP en première position.
- En mode tunnel, la protection porte sur tout le paquet IP original. C'est-à-dire, le paquet IP original est chiffré avant d'être encapsulé dans l'extension ESP. Cette extension est alors placée dans un nouveau paquet IP dont les en-têtes IP sont en clair (non chiffrés) pour permettre au réseau IP de correctement acheminer le paquet (cf. figure Positionnement de l'extension ESP en modes transport et tunnel). Il s'agit du classique chiffrement des artères. La protection en intégrité/authentification porte sur l'extension ESP (comprenant le paquet IP original) excepté l'authentificateur ESP. L'extension ESP rend le service de confidentialité du flux de façon limitée en ce sens que ce service n'est rendu qu'en mode tunnel et ne porte que sur la confidentialité des adresses IP. En effet, l'extension ESP en mode tunnel réalise le chiffrement de l'intégralité des paquets IP originaux, y compris leurs adresses IP. De ce fait, si les équipements qui mettent en oeuvre IPsec ne sont pas l'émetteur et le destinataire final des paquets, leurs adresses masqueront celles de ces derniers. Un intrus placé en écoute sur le réseau au niveau d'un tunnel IP (entre les passerelles de sécurité) ne pourra pas dans ce cas là connaître les adresses des stations en communication.
Contenu de l'extension ESP
L'extension ESP est composée des champs suivants (cf. figure Format de l'extension d'ESP) :
- Le champ indice de paramètres de sécurité (SPI) combiné à l'adresse du (des) destinataire(s), identifie l'association de sécurité utilisée pour construire cette extension.
- Le numéro de séquence permet de détecter les rejeux de paquet IP.
- Le champ charge utile peut contenir soit un paquet IP complet (en-tête IP + extensions + données de niveau transport), soit l'extension destination suivie de données de niveau transport, soit des données de niveau transport uniquement.
- Ce champ peut également contenir des données de synchronisation selon les algorithmes de chiffrement utilisés.
- Le champ bourrage permet d'ajouter des bits de bourrage pour aligner les données à chiffrer sur un nombre d'octets dépendant de l'algorithme de chiffrement utilisé. Le champ bourrage est optionnel. Sa présence est précisée par l'association de sécurité utilisée.
- Le champ longueur du bourrage indique la longueur en octets du champ bourrage.
- Le champ en-tête suivant identifie le type de données contenues dans le premier champ du champ charge utile.
- Le champ authentificateur est optionnel et sa présence dépend de l'association de sécurité utilisée (SPI + adresse(s) de destination + ESP). Il est calculé à l'aide de l'algorithme et de la clé correspondant à l'association de sécurité.
Notez que le champ en-tête ESP inclut l'indice des paramètres de sécurité et le numéro de séquence, tandis que le champ queue ESP comprend les champs bourrage, longueur du bourrage et en-tête suivant.
La détection de rejeu est optionnelle car lors de la génération d'une extension ESP, il est nécessaire de préciser un numéro de séquence adéquat dans le champ numéro de séquence tandis qu'à l'extraction de l'extension ESP, la vérification du numéro de séquence n'est pas obligatoire.
Le RFC 2406 précise les algorithmes de chiffrement que doivent obligatoirement implémenter les équipements IPsec pour rendre le service de confidentialité. Si dans le RFC 2406, seul l'algorithme DES dans le mode d'utilisation CBC (Cipher Block Chaining) est mentionné obligatoire, au fil du temps, l'IETF a fait évoluer la liste en ajoutant en 1999 le triple DES et plus récemment l'AES (Advanced Encryption Stantard). Quant à la génération de l'authentificateur, les mêmes mécanismes que pour l'extension AH sont préconisés par défaut, à savoir HMAC- MD5, HMAC-SHA-1.
Le chiffrement des données dans l'extension ESP n'est pas obligatoire. Dans ce cas, seuls les services d'intégrité/authentification sont rendus, mais ils ne portent que sur l'extension ESP, contrairement à l'extension AH qui porte sur tout le paquet IP excepté certains champs "modifiables" par le réseau. Dans certains cas, suivant le niveau de protection en intégrité souhaité, il peut être nécessaire d'utiliser les deux extensions AH et ESP dans le même paquet, l'extension ESP ne rendant alors que le service de confidentialité.
L'extension ESP souffre tout comme l'extension AH d'incompatibilités avec le mécanisme de traduction d'adresse, et ce, bien que l'authentification réalisée ne porte que sur le contenu de l'en-tête ESP ; cependant contrairement à AH, il existe une solution palliative présentée ci-dessous. Le problème d'incompatibilité de ESP en mode transport avec la traduction d'adresses seules est lié aux protocoles TCP et UDP qui définissent un champ de contrôle dont le calcul fait intervenir les adresses IP ; ainsi la modification d'une adresse suppose la modification de ce contrôle, ce qui n'est pas réalisable avec ESP en mode transport ; en effet, soit le chiffrement est activé dans ESP et le champ de contrôle est inaccessible car chiffré ; soit les services d'authentification/intégrité sont activés, et la modification du champ de contrôle conduira à la détection d'un problème d'intégrité du paquet et au rejet du paquet par l'équipement IPsec récepteur.
Le fait de traduire en plus des adresses les numéros de port ajoute encore davantage d'incompatibilités. Pour ESP, c'est l'encapsulation elle-même qui pose problème car elle rend les numéros de port soit inaccessibles (chiffrement activé), soit interdits de modification (car protégés en intégrité). Enfin, noter que pour ESP en mode tunnel, les numéros de port sont inexistants.
Une solution est aujourd'hui définie pour pallier à cette incompatibilité. Elle consiste à n'utiliser que le protocole ESP (mode transport ou tunnel) et à réaliser une encapsulation UDP supplémentaire. Plus précisément, un tunnel UDP doit être établi entre les deux équipements IPsec ; les données encapsulées dans ce tunnel sont protégées par le protocole ESP. Ainsi, la traduction des adresses/numéros de port donne lieu à la modification du champ de contrôle de UDP sans porter atteinte à l'intégrité de l'en-tête ESP et la traduction de numéros de port est faite sur les numéros de port UDP qui sont accessibles ici. Afin de détecter la traversée d'un équipement de traduction d'adresse et n'activer l'encapsulation UDP que lorsque nécessaire, les passerelles IPsec peuvent faire appel au mécanisme de NAT-traversal [RFC 3947] [RFC 3948] lors de l'établissement dynamique d'une association de sécurité.
Évolutions prévues
La prochaine version de l'extension ESP intègre les mêmes évolutions que AH concernant l'identification des associations de sécurité et les numéros de séquence. Tout comme pour AH, il est prévu que la liste des algorithmes obligatoires soit précisée dans un document indépendant et tenu à jour.
Il est également prévu de permettre l'usage d'un plus grand nombre d'algorithmes, comme les algorithmes dits "combinés" qui permettent simultanément de chiffrer et de protéger en intégrité. Ces algorithmes combinés nécessitent un aménagement du format de ESP. En effet, certains d'entre eux n'assurent l'intégrité que sur les données chiffrées ; d'autres peuvent étendre la protection en intégrité sur des champs extérieurs. Compte tenu que l'indice de paramètres de sécurité et le numéro de séquence ne sont pas chiffrés mais nécessitent d'être protégés en intégrité, il peut être nécessaire de les faire apparaître deux fois dans le paquet : dans l'en-tête ESP et dans la charge utile. De façon à rendre l'extension ESP ouverte à un grand nombre d'algorithmes, le champ authentificateur n'est plus tenu de tenir sur un nombre entier de 32 mots.
Afin de se prémunir des analyses statistiques portant sur les flots de données chiffrés, la prochaine version de la RFC 2406 prévoit d'assurer le service de confidentialité du flux. La technique utilisée consiste à introduire des données de bourrage (sans signification) dans les paquets IP. À cette fin, un nouveau champ optionnel - Traffic Flow Confidentiality - est défini et se trouve positionner dans la charge utile.
Enfin, trois configurations de ESP sont distinguées suivant que sont rendus le service d'intégrité seul, le service de confidentialité seul ou simultanément les services d'intégrité et de confidentialité. Cette distinction permet d'optimiser le traitement des paquets, et de permettre l'usage d'algorithmes combinés. Noter que le service de confidentialité est optionnel et peut donc ne pas être implémenté dans ESP.
| |
Extension d'authentification AH | Table des matières | Gestion des associations et des clés | |
| |
Déplacements des mobiles | Table des matières | Les risques induits par la mobilité et leur limitation | |
Format général du paquet
Nous avons vu que les en-têtes de mobilité sont utilisés pour transporter la signalisation de la gestion des associations de mobilité entre le noeud mobile, son agent mère et le noeud correspondant.
Un en-tête de mobilité ne doit jamais être utilisé en même temps qu'un en-tête de routage de type 2, excepté dans le seul cas du transport d'un acquittement d'une demande de BU. Il ne doit jamais non plus être utilisé en même temps qu'une extension de destination, sauf dans certains cas de Binding Update avec l'agent mère ainsi qu'avec des noeuds correspondants déjà identifiés.
Le format général d'un en-tête de mobilité est donné figure Format de l'extension de mobilité :
- Le champ en-tête suivant est pris dans le même espace de numérotation que les en-têtes d'extension d'IPv6 (cf. Valeurs du champ en-tête suivant). Dans le cas de la signalisation de mobilité, il doit valoir 59 (pas d'en-tête suivant).
- Le champ longueur de l'en-tête, en octets, ne prend pas en compte les 8 premiers octets de l'en-tête.
- Le champ type d'en-tête décrit les messages de signalisation donné au tableau Type des en-têtes de mobilité.
| 0 | Demande de rafraîchissement émise par le noeud correspondant |
| 1 | Initialisation de test d'adresse mère (HoTI) |
| 2 | Initialisation de test d'adresse temporaire (CoTI) |
| 3 | Test d'adresse mère (HoT) |
| 4 | Test d'adresse temporaire (CoT) |
| 5 | Mise à jour d'association (émise depuis le noeud mobile) |
| 6 | Acquittement de mise à jour d'association |
| 7 | Erreur de mise à jour d'association |
La structure et la longueur du message varient en fonction du numéro de l'en-tête. De plus, MIPv6 définit également des options de mobilité associées à ces messages. Comme la longueur des messages associés à chaque numéro d'en-tête est connue, la présence d'une option est déduite d'une longueur de l'en-tête plus grande que ce qui est suffisant pour le message. Elle se trouve forcément à la suite du message.
Comme toutes les en-tête IPv6, ces en-têtes de mobilité doivent être alignés sur des frontières de 8 octets. Des champs réservés seront éventuellement insérés pour respecter cette contrainte. Un noeud ne sachant pas interpréter une option doit l'ignorer. Actuellement MIPv6 ne définit d'option que pour les messages de BU (type 5) et leur acquittement (type 6).
Format des messages et options des différents types d'en-têtes
La demande de rafraîchissement d'association ne requiert aucune information spécifique. Le message est vide, il n'y a pas d'option. (cf. figure Format de l'extension de mobilité rafraîchissement d'association).
Les messages HoTI, CoTI ne contiennent que le nombre aléatoire émis par le noeud mobile. Il ne contient pas d'option. (cf. figure Format de l'extension de mobilité HoTI ou CoTI).
Les messages HoT, CoT contiennent, l'index du nombre aléatoire (nonce) choisi par le noeud correspondant, le nombre aléatoire émis par le noeud mobile (cookie), (pour le test home address ou care-of address) et le jeton chiffré (keygen token) émis par le noeud correspondant. Il ne contient pas d'option (cf. figure Format de l'extension de mobilité HoT ou CoT).
Les messages de notification de mise à jour d'association, émis par le noeud mobile, peuvent contenir des options mobiles. Si elles ne sont pas présentes, le paquet doit se terminer par 4 octets de bourrage. (cf. figure Format de l'extension de mobilité mise à jour d'association)
Les options possibles sont :
- Les données d'autorisation de mise à jour d'association. L'option est obligatoire pour les mises à jour émises vers le noeud correspondant puisqu'elles ne sont pas protégées par IPsec.
- L'indice du "nonce" choisi par le noeud correspondant.
- Une "care-of address" alternative.
Les message d'acquittement de mise à jour d'association peut contenir des options mobiles. Si elles ne sont pas présentes, le paquet doit être terminé par 4 octets de bourrage. (cf. figure Format de l'extension de mobilité acquittement de mise à jour d'association) :
- Une valeur du champ statut inférieure à 128 indique un acquittement, et une valeur supérieure un rejet. Le motif du rejet est codé par la valeur du statut.
- Le bit K = 1 indique que l'association de sécurité IPsec suivra les mouvements du noeud mobile. Le noeud correspondant doit le positionner à 0.
- Les options possibles sont :
- Les données d'autorisation de mise à jour d'association.
- Les informations de fréquence de rafraîchissement des associations.
Les messages d'erreur de mise à jour d'association contiennent un statut sur 8 bits codant l'erreur, ainsi que la home address de la mise à jour en erreur pour le cas où le noeud mobile aurait établi plusieurs associations avec le noeud correspondant (cf. figure Format de l'extension de mobilité message d'erreur).
| |
Déplacements des mobiles | Table des matières | Les risques induits par la mobilité et leur limitation | |
