From bc1d70343807104ccf64b6bde9b2db54270203ff Mon Sep 17 00:00:00 2001 From: neodarz Date: Fri, 10 Mar 2017 11:58:22 +0100 Subject: Initiale release --- ...rations_for_IPv6_AdaptationLayer_Mechanisms.txt | 127 +++++++++++++++++++++ 1 file changed, 127 insertions(+) create mode 100644 RFC_8065_Privacy_Considerations_for_IPv6_AdaptationLayer_Mechanisms.txt (limited to 'RFC_8065_Privacy_Considerations_for_IPv6_AdaptationLayer_Mechanisms.txt') diff --git a/RFC_8065_Privacy_Considerations_for_IPv6_AdaptationLayer_Mechanisms.txt b/RFC_8065_Privacy_Considerations_for_IPv6_AdaptationLayer_Mechanisms.txt new file mode 100644 index 0000000..5e761ed --- /dev/null +++ b/RFC_8065_Privacy_Considerations_for_IPv6_AdaptationLayer_Mechanisms.txt @@ -0,0 +1,127 @@ +Titre: RFC 8065: Privacy Considerations for IPv6 Adaptation-Layer Mechanisms +Auteur: +Date: Fri 24 Feb 2017 01:00:00 +0100 +Lien: https://www.bortzmeyer.org/8065.html + +Entre la couche 3 (du modèle en couches) et la couche 2 (par exemple Ethernet) +se trouve une adaptation, qui définit comment on va mettre les paquets IPv6 sur +la couche sous-jacente. Certaines de ces adaptations posent des problèmes de +protection de la vie privée. Ce RFC résume les problèmes existants. Chaque +adaptation devra ensuite travailler à s'améliorer sur ce plan (le RFC donne des +idées). L'idée est d'améliorer les normes actuelles et futures, pour mieux +prendre en compte ce problème de vie privée. + +Ce problème de la vie privée pour IPv6 a déjà été beaucoup discuté, notamment +en raison d'un choix initial de privilégier une adaptation à Ethernet qui +gardait une partie de l'adresse IPv6 constante, même quand la machine changeait +de réseau. Ce problème est résolu depuis longtemps (RFC 4941) mais d'autres +peuvent demeurer, surtout si la couche 2 a des contraintes qui empêchent de +déployer certaines protections de la vie privée. + +Les documents de référence à lire d'abord sont le RFC général sur la vie +privée, RFC 6973 (sa section 5.2 est particulièrement utile ici), et, plus +spécifique à IPv6, le RFC 7721. Le risque qui concerne l'adaptation est lié au +mécanisme de génération des IID (identificateurs d'interface, cf. RFC 4291), +puisque cet IID fait partie de l'adresse IPv6 (typiquement les 64 derniers +bits) et va donc être potentiellement visible publiquement. Si l'IID est trop +prévisible ou trop stable, il permettra notamment : + + * De corréler des activités du même utilisateur au cours du temps, + * De suivre l'utilisateur à la trace s'il se déplace en gardant le même IID, + * De balayer plus facilement un réseau à la recherche de machines à attaquer + (alors que, normalement, la taille élevée de l'espace d'adressage IPv6 rend + ces balayages lents et pénibles). + +Un concept important est celui d'entropie, c'est-à-dire du nombre de bits dans +l'IID qui sont réellement imprévisibles. Idéalement, l'entropie devrait être de +64 bits (le préfixe IPv6 ayant typiquement une longueur de 64 bits pour un +réseau, cf. RFC 7421). + +Voilà pourquoi le RFC 8064 déconseille de créer un IID à partir d'une adresse +« couche 2 » fixe, comme l'est souvent l'adresse MAC. Il recommande au +contraire la technique du RFC 7217 si on veut des adresses stables tant qu'on +ne se déplace pas, et celle du RFC 4941 si on veut être vraiment difficile à +tracer (au prix d'une administration réseaux plus difficile). Le RFC sur la +sélection des adresses source, RFC 6724 privilégie déjà par défaut les adresses +temporaires du RFC 4941. + +Revenons maintenant à cette histoire d'entropie (section 2 du RFC). Combien de +bits sont-ils nécessaires ? Prenons le cas le plus difficile, celui d'un +balayage du réseau local, avec des paquets ICMP Echo Request ou bien avec des +TCP SYN. L'entropie minimum est celle qui minimise les chances d'un attaquant +de trouver une adresse qui réponde. Quel temps faudra t-il pour avoir une +chance sur deux de trouver une adresse ? (Notez que la capacité de l'attaquant +à trouver des machines dépend aussi du fait qu'elles répondent ou pas. Si une +machine ne répond pas aux ICMP Echo Request, et n'envoie pas de RST aux paquets +TCP SYN, la tâche de l'attaquant sera plus compliquée. Cf. RFC 7288, notamment +sa section 5. Même si la machine répond, un limiteur de trafic peut rendre la +tâche de l'attaquant pénible. Avec la valeur par défaut d'IOS de deux réponses +ICMP par seconde, il faut une année pour balayer un espace de seulement 26 +bits.) + +Les formules mathématiques détaillées sont dans cette section 2 du RFC. +L'entropie nécessaire dépend de la taille de l'espace d'adressage mais aussi de +la durée de vie du réseau. Avec 2^16 machines sur le réseau (c'est un grand +réseau !) et un réseau qui fonctionne pendant 8 ans, il faudra 46 bits +d'entropie pour que l'attaquant n'ait qu'une chance sur deux de trouver une +machine qui réponde (avec la même limite de 2 requêtes par seconde ; sinon, il +faudra davantage d'entropie). + +Et combien de bits d'entropie a-t-on avec les techniques actuelles ? La section +3 donne quelques exemples : seulement 48 bits en Bluetooth (RFC 7668), 8 (oui, +uniquement 256 adresses possibles, mais c'est nécessaire pour permettre la +compression des en-têtes) en G.9959 (RFC 7428) et le pire, 5 bits pour NFC (RFC +pas encore paru). + +Ces adaptations d'IPv6 à diverses couches 2 utilisent comme identificants +d'interface des adresses IEEE (comme les adresses MAC) ou bien des « adresses +courtes ». Commençons par les adresses reposant sur des adresses IEEE. Dans +certains cas, la carte ou la puce qui gère le réseau dipose d'une adresse +EUI-48 ou EUI-64 (comme l'adresse MAC des cartes Ethernet). On peut facilement +construire une adresse IPv6 avec ces adresses, en concaténant le préfixe avec +cette adresse IEEE utilisée comme identificateur d'interface (IID). L'entropie +dépend du caractère imprévisible de l'adresse IEEE. L'IEEE a d'ailleurs des +mécanismes[1] (pas forcément déployés dans le vrai monde) pour rendre ces +adresses imprévisibles. Même dans ce cas, la corrélation temporelle reste +possible, sauf si on change les adresses de temps en temps (par exemple avec +macchanger[2]). + +Un argument souvent donné en faveur des adresses MAC est leur unicité, qui +garantit que les adresses IPv6 seront « automatiquement » distinctes, rendant +ainsi inutile la détection d'adresses dupliquées (DAD, RFC 4862, section 5.4, +et RFC 4429, annexe A). Sauf que ce n'est pas vrai, les adresses MAC ne sont +pas forcément uniques, en pratique et les identificateurs d'interface +aléatoires sont donc préférables, pour éviter les collisions d'adresses. + +En dehors des adresses allouées par un mécanismes de l'IEEE, il y a les +« adresses courtes » (16 bits, utilisées par IEEE 802.15.4, cf. RFC 4944), +allouées localement, et uniques seulement à l'intérieur du réseau local. Vu +leur taille, elles n'offrent évidemment pas assez d'entropie. Il faut donc les +étendre avant de s'en servir comme identificateur d'interface. Le RFC cite par +exemple un condensat de la concaténation de l'adresse courte avec un secret +partagé par toutes les machines du réseau. + +On peut aussi utiliser dans le condensat le numéro de version spécifié dans la +section 4.3 du RFC 6775. Ainsi, un changement de numéro de version permettra +une rénumérotation automatique. + +Bien, après cette analyse, les recommandations (section 4) : + + * La section Sécurité (Security Considerations) des RFC qui normalisent une + adaptation à une couche 2 donnée devrait dire clairement comment on limite + le balayage. Cela nécessite de préciser clairement la durée de vie des + adresses, et le nombre de bits d'entropie. + * Il faut évidemment essayer de maximiser cette entropie. Avoir des + identificateurs d'adresses aléatoires est une bonne façon de le faire. + * En tout cas, pas question de juste utiliser une adresse courte et stable + avec quelques bits supplémentaires de valeur fixe et bien connue. + * Les adresses ne devraient pas être éternelles, pour limiter la durée des + corrélations temporelles. + * Si une machine peut se déplacer d'un réseau à l'autre (ce qui est courant + aujourd'hui), il faudrait que l'identifiant d'interface change, pour + limiter les corrélations spatiales. + + +Liens: +[1]: https://mentor.ieee.org/privecsg/documents (lien) +[2]: http://www.gnu.org/software/macchanger (lien) -- cgit v1.2.1