Nous avons précédemment discuté des notions de syntaxe et de classification des adresses IPv6. Il reste toutefois encore un sujet à aborder dans ce domaine, la question de l’adressage en lui-même. Il ne sera pas ici question d’effectuer un plan d’adressage, mais bel et bien des contraintes entourant la distribution et la confection des adresses IPv6 pour chaque entité du réseau.

Approche automatisée

IPv6 prévoit, au sein des RFC 4291 et 4862, des mécanismes lui permettant un fonctionnement autonome, sans avoir besoin de services additionnels, comme par exemple un serveur DHCP (Dynamic Host Configuration Protocol). Cette approche, souvent référencée sous le terme d’auto-configuration (ou configuration automatique), se repose sur des informations préexistantes afin de constituer une adresse IPv6 potentiellement unique pour chaque interface.

Chaque interface dispose, d’usine, d’un identifiant généralement unique gravé (Burned In Address ou BIA) en son sein. Cet identifiant, généralement connu sous le nom d’adresse MAC (Media Access Control) peut toutefois prendre différentes formes en fonction de paramètres spécifiques. Le principal paramètre est formé par le bit U/L (Universal / Local), soit le 7e bit de poids fort (avant dernier bit du premier octet). Ce bit permet de déterminer si l’identifiant considéré est globalement attribué (initialisé à 0) ou s’il est administré localement (initialisé à 1).

L’IEEE a instauré des distinctions entre les différents types d’adresses, avec les identifiants universels devenant des EUI (Extended Unique Identifier), tous les autres demeurant du même fait de « simples » MAC. Cette distinction ne change, pour l’utilisateur final, absolument rien, et ses seules implications vont se retrouver notamment au sein d’IPv6. En effet, quel que soit le type d’adresse matérielle utilisée, unique ou non, qu’elle ait une taille de 48 (soit la version habituelle) ou 64 bits (majoritairement utilisée au sein du FireWire), IPv6 va se reposer sur l’usage d’un identifiant, appelé suffixe, formé par la méthode dite modified EUI-64.

Cet identifiant permet de constituer invariablement toujours des suffixes de 64 bits de longueur, soit la taille réservée afin d’identifier une interface en particulier. Il est possible de remarquer, dans la figure ci-dessus, les mécanismes utilisés afin de créer ces suffixes. Le premier point important concerne les identifiants de 48 bits, insuffisamment long pour remplir l’espace de 64 bits alloué. Afin que l’OUI occupe systématiquement le même emplacement, il est ici séparé de l’identifiant d’interface par les 4 digits hexadécimaux FFFE, soit 16 bits, amenant l’ensemble à 64 bits.

Le second point se base sur une observation simple : l’adressage IPv6 et les adresses IPv6 en particulier, peuvent s’avérer longues à écrire, configurer, se souvenir, … Dans le cadre présent, lorsque l’auto-configuration s’applique, celle-ci se reposera sur l’usage d’adresses matérielles EUI. Toute adresse définie manuellement devrait, en théorie, respecter les bits UG de l’identifiant d’interface. Prenons l’exemple suivant afin de clarifier ce point :

On remarque rapidement dans cet exemple le principale (et seul) bénéfice à utiliser le modified EUI-64 dans le cadre des adresses IPv6 : cela permet de sensiblement simplifier l’écriture des adresses manuelles, tout en ne modifiant que modestement les adresses automatiques, puisqu’il suffit d’ajouter 2 au second digit hexadécimal du suffixe d’interface pour les obtenir. Il est important de noter que modifier ce bit au sein des adresses IPv6 n’a aucun impact sur la portée des adresses. En effet, seul le préfixe prévaut dans cette détermination, ce bit n’ayant son utilité que dans caractérisation des adresses matérielles indépendamment d’autres facteurs.

Cette méthode de configuration est hautement recommandée (RFC 4291) car elle apporte des bénéfices non négligeables : la configuration est automatique, mais demeure efficace (basée sur une information connue et massivement déployée), cohérente et adaptable à une majorité de situations. Il existe toutefois, en dehors de DHCPv6, deux autres mécanismes majeurs de configuration dite automatique, au travers d’une configuration du suffixe d’interface de manière aléatoire ou cryptographique.

L’approche aléatoire

S’ils offrent l’avantage d’être uniques, les suffixes basés sur des informations immuables (adresses matérielles) peuvent poser des problèmes de confidentialité et de sécurité. En effet, un tel suffixe étant toujours identique pour une interface donnée, il devient très facile de tracer une personne sur son lieu de travail ou à son domicile afin d’en retirer des informations cruciales : horaires de travail, présence ou non au domicile, itinérance d’un terminal entre le domicile et le lieu de travail, etc.

La RFC 4941, dont le détail des mécanismes sort du cadre de cet article, n’adresse que certains cas, et ne peut par exemple en aucun cas résoudre les problèmes liés à l’usage de serveurs de résolution de nom pour un hôte muni d’un nom spécifique (et pas seulement d’une adresse IP). L’extension faite ici aux mécanismes d’auto-configuration s’avère intéressante puisqu’elle permet de renforcer la discrétion d’un terminal en lui fournissant toujours une adresse IP différente après une certaine période de temps donnée.

Le suffixe est généré de manière aléatoire, ou pseudo-aléatoire dans le cas présent, puisqu’il est en pratique impossible d’obtenir une entropie (un caractère aléatoire) parfaite en informatique. Toutefois, le processus entier est automatique, et la configuration de l’interface demeure elle-aussi automatisée, seul le résultat (le suffixe sélectionné) change. Il existe deux méthodes de génération différentes. La première se repose sur l’usage des suffixes précédemment générés afin de créer un nouveau suffixe, nécessitant du même fait une unité de stockage. La seconde méthode ne stocke aucune information, et crée à la volée des suffixes afin d’engager le même processus que précédemment. L’une comme l’autre crée un hash (MD5 prévu, mais d’autres algorithmes peuvent être considérés) du résultat qui sert par la suite de suffixe à l’adresse IPv6.

Chaque méthode a ses propres avantages et inconvénients. La première nécessite une unité de stockage, mais est sensiblement plus performante que la seconde, n’ayant pas besoin de générer à chaque fois des suffixes. L’autonomie de la seconde est intéressante puisqu’elle ne se repose pas sur une unité de stockage potentiellement faillible (corruption des données, défectuosité, …) et recrée l’ensemble du mécanisme à chaque fois. L’une comme l’autre nécessite toutefois de se reposer sur des algorithmes de génération aléatoire performants, tels que défini notamment dans la RFC 4086.

Ce mécanisme offre l’avantage de renouveler régulièrement l’adresse d’une interface, évitant du même fait la potentielle exploitation des informations liées au mouvement d’une entité (homme ou machine), évitant dès lors de l’exposer trop fortement à des attaques ciblées. Toutefois, il n’est pas exempt de défaut, et certaines applications et services peuvent refuser de fonctionner correctement avec des adresses aléatoires, notamment s’ils tentent de faire correspondre un nom d’hôte avec un enregistrement DNS. Dès lors, l’usage d’adresses temporaires aléatoires se doit de rester une option du système, mais aussi des applications souhaitant l’utiliser.

L’approche cryptographique

Cette approche, décrite en détails dans la RFC 3972, définit une procédure permettant de créer, à partir de la clé publique de l’hôte, un identifiant d’interface à accoler à notre préfixe IPv6. Se reposant sur des notions cryptographiques, les mécanismes peuvent s’avérer rapidement complexes. Nous allons ici nous contenter de décrire le processus général par lequel ce suffixe est généré, ce qui représente déjà un procédé potentiellement long et relativement complexe.

Si la clé publique représente le paramètre principal sur lequel se repose l’ensemble des mécanismes, il serait trop simplifier de définir le suffixe trouvé comme étant les 64 premiers bits du hash SHA-1 de celle-ci. En effet, de nombreux autres paramètres entrent en ligne de compte, permettant d’assurer l’authenticité, l’unicité et la confidentialité des informations utilisées pour créer le suffixe. L’approche cryptographique est majoritairement utilisée dans le cadre de SEND (SEcure Neighbor Discovery), et de ce fait nécessite des procédures robustes permettant de confirmer et valider une adresse en particulier. Ces paramètres sont les suivants :

  • Un modificateur, soit une valeur de 128 bits (16 octets) aléatoires ou pseudo aléatoires.
  • La clé publique en elle-même.
  • Le préfixe IPv6.
  • Un compteur de collision.
  • Une série de 9 octets à 0 (soit 72 bits à 0 ou 18 digits hexadécimaux).

Deux étapes successives permettent de créer puis de valider le suffixe définit. Ces deux étapes sont décrites dans les figures suivantes. La première étape consiste à générer le suffixe à partir de la clé publique.

Il est intéressant de noter ici que la génération de H2 peut boucler pendant un certain temps (boucle α) avant qu’une correspondance soit trouvée. Cette correspondance sera d’autant plus compliquée à déterminer que le paramètre de sécurité SEC sera grand (dont la valeur est, pour rappel, comprise entre 0 et 7). Définir SEC = 0 permet de rentre l’ensemble du processus plus rapide, mais réduit d’autant la pertinence sécuritaire de cette approche. A l’heure actuelle, un paramètre SEC = 7 garantit un niveau de sécurisation infaillible (sur base des ressources accessibles actuellement).
La seconde étape, quant à elle, se déroule non pas au niveau de l’hôte détenteur de la clé publique, mais de sa destination. Celle-ci va opérer des vérifications à partir du premier jeu de données reçu, correspondant aux paramètres utilisés pour générer le suffixe. Dans le cas où la moindre erreur surviendrait (incohérence ou résultat différent), le processus est immédiatement stoppé et la procédure complète doit être réinitialisée.

Lorsque le processus de validation est couronné de succès, la destination est certaine de deux points essentiels : la source de la requête est effectivement celle qu’elle prétend être, et la clé publique reçue est elle aussi authentique. De ce fait, il est possible, pour les deux entités, de communiquer de manière sécurisée.

Ces deux mécanismes associés permettent par conséquent de garantir aux différentes parties leur authenticité respective, sans pour autant devoir se référer à une autorité centralisée (comme par exemple PKI ou Private Key Infrastructure). Cette absence d’autorité va permettre des usurpations d’identité qui resteront cependant lettre morte puisque, par la vérification associée et la difficulté, pour une tierce personne, de casser les hash successifs, il n’y a aucune chance, à l’heure actuelle, pour que cette personne soit en mesure de passer la succession de tests.

Chacune des méthodes décrites ici présente des avantages et des inconvénients, mais ce qu’il convient de retenir en particulier ici est que les deux alternatives abordées n’ont réellement leur utilité que dans des cas très spécifiques où la sécurisation du poste ou du détenteur devient une priorité extrême. En règle générale, à l’heure actuelle, la majeure partie des implémentations considèrent l’utilisation de l’auto-configuration à l’aide des modified EUI-64 ou d’une approche « standard » à l’aide d’un DHCP. Il est toutefois important de noter que des alternatives existent. Elles sont certes moins performantes du point de vue de la génération du suffixe, mais offrent un niveau de confidentialité particulièrement attractif pour certains secteurs d’activité ou pour du personnel mobile et sujet à une surveillance numérique permettant de savoir exactement quand et où un individu donné se trouve…