Le futur d'Internet est l'adressage IPv6 en lieu et place de l'actuel protocole IPv4, puisque nous sommes en train d'atteindre les limites de ce dernier.
Malgré ses indéniables atouts, le protocole IPv6 pose certaines questions sur le respect de la vie privée lors de sa configuration automatique. Nous proposons dans cette dépêche de passer en revue les problèmes et d'esquisser des solutions afin de mieux protéger sa vie privée avec IPv6.
Sommaire
- Connexion aux réseaux en IPv6 avec l'autoconfiguration
- RFC 4941 : rendre les adresses auto-configurées temporaires
- RFC 7217 : créer par défaut des identifiants d'interface non-prédictibles et stables
- Conclusion
Le protocole IPv6 a un très grand avantage sur son ancêtre : la taille des adresses passe de 32 à 128 bits. Ça n'a l'air de rien comme ça, mais cette profusion d'adresses résout beaucoup de problèmes d'IPv4 sans nécessiter la complexité de ce dernier :
- il n'y a plus besoin de créer des réseaux « privés » (avec un NAT) puisque le nombre d'adresses disponibles est largement suffisant. Ainsi, si les règles de routage le permettent, les clients peuvent être connectés directement entre eux (ce qui facilite l'adoption des connexions P2P). Ne pas avoir à configurer de NAT est un grand avantage également pour l'auto-hébergement, car il n'y a pas besoin de gérer l'ouverture et la redirection des ports du routeur, ce qui simplifie grandement sa configuration, puisque "seul" le pare-feu doit être géré ;
- il n'y a plus de nécessité de coordinateur central pour gérer les baux d'adresses d'un sous-réseau (DHCP), puisqu'il suffit de tester si une adresse tirée au hasard est disponible, tester si quelqu'un l'utilise et l'utiliser (ou tester une nouvelle) ;
- les cartes réseau peuvent louer autant d'adresses que désiré, puisque les sous-réseaux contiennent suffisamment d'adresses disponibles (bien plus que les fameuses 255 adresses fournies par les réseaux privés installés par défaut) ;
- le routeur est capable de s'annoncer directement sur le réseau pour tous les appareils lui étant connectés par le réseau « lien-local » (i.e. physiquement branché sur le même réseau). Ainsi, les clients peuvent se configurer automatiquement pour avoir accès au reste d'Internet. Ceci est possible grâce à la possibilité d'avoir plusieurs adresses par interface : une adresse lien-local utilisée pour recevoir les informations et mises à jour du réseau local et une adresse globale pour se connecter au reste d'Internet.
Malgré tous ces avantages, un des inconvénients connus d'IPv6 est que le fichage du trafic des ordinateurs particuliers est plus aisé par les attaquants. En effet, une des propriétés du protocole NAT était d'utiliser une seule adresse IPv4 publique pour plusieurs appareils, ce qui rendait un peu plus difficile le fichage des utilisateurs, puisque plusieurs d'entre eux utilisaient la même adresse pour se connecter à Internet.
Avec IPv6, chaque ordinateur ayant sa propre adresse publique, l'attaquant peut faire un lien direct entre une adresse et un utilisateur particulier.
Un attaquant pourrait être un homme du milieu qui écouterait le trafic IP ou une personne ayant accès à des logs de différents serveurs. Avec de telles informations, l'attaquant pourrait faire des liens entre les différentes activités des utilisateurs, bien qu'elles ne soient pas liées directement.
Par exemple, il pourrait savoir quand un employé travaille sur Internet ou quand une personne est présente chez elle.
Il faudrait donc veiller à ce que les machines du réseau changent d'adresse IP publique régulièrement pour rendre le fichage plus difficile. Il pourrait changer à travers le temps et/ou selon le réseau auquel il se connecte.
Dans la suite de cette dépêche, nous vous proposons d'analyser les moyens à disposition des utilisateurs pour rendre difficile le fichage des utilisateurs par les serveurs au moyen d'adresses IPv6.
Connexion aux réseaux en IPv6 avec l'autoconfiguration
Pour commencer, il faut savoir que les adresses IPv6 sont définies en deux parties :
- le préfixe réseau qui est défini par le FAI. Il est annoncé sur le réseau par le routeur au moyen des adresses de type lien-local.
- l'identifiant d'interface qui se compose des bits restants et qui identifie une interface d'une machine dans le réseau.
Quand un appareil connecte son interface sur un réseau, ce dernier crée automatiquement une adresse de type lien-local avec le préfixe réseau [fe80::]/10. Ces adresses ne doivent être utilisées qu'à l'intérieur d'un même réseau (donc les routeurs ne doivent pas permettre de connexion sortante) et permettent de découvrir les autres appareils connectés sur le même réseau.
Grâce à cette adresse locale, la machine peut écouter les annonces diffusées par le routeur sur le réseau. Avec ces annonces, la machine reçoit de la part du routeur le préfixe réseau à utiliser pour communiquer avec l'extérieur.
Comme l'appareil est connecté au réseau local, il peut aussi communiquer avec les autres appareils du réseau et contrôler quels identifiants d'interface sont déjà utilisés par les autres (il crée un identifiant d'interface, il annonce qu'il souhaite l'utiliser et il peut l'utiliser si aucun des voisins ne l'utilise déjà).
Afin de trouver plus rapidement un identifiant d'interface réseau non-utilisé, si la taille du préfixe réseau le permet (inférieure ou égale à 64 bits), la machine peut tenter d'utiliser l'adresse MAC de son interface réseau comme identifiant. Cependant, comme l'adresse MAC devrait être unique à l'interface réseau de la machine, l'adresse IP trouvée sera non seulement globalement unique (après contrôles avec son voisinage), mais également invariable.
Les deux RFCs que nous allons analyser proposent des solutions pour ce système de configuration automatique qui utilise les adresses MAC, afin d'utiliser des identifiants moins constants à travers le temps et les réseaux. Leur objectif est de ne plus utiliser directement sur le réseau une adresse IP invariable, afin de protéger l'utilisateur d'un potentiel fichage.
RFC 4941 : rendre les adresses auto-configurées temporaires
Cet RFC propose de rendre le pistage du trafic d'un client IPv6 plus difficile en étendant la définition des types d'adresses IPv6 avec un type temporaire.
Il propose une solution pour résoudre les problèmes suivants :
- Comme l'identifiant d'interface reste constant à travers tous les réseaux auxquels le client se connecte, un attaquant, qui aurait accès aux logs de différents serveurs, peut trouver des corrélations entre les différentes activités du client.
- Un attaquant qui écouterait le trafic du réseau peut facilement retrouver les communications d'un client précis en lisant les données IPv6 des paquets réseau.
Il identifie également que sa solution ne peut pas résoudre la découverte de corrélation utilisant :
- les données utiles transportées par les paquets
- les caractéristiques des paquets telles que leur taille et leur chronologie
- le préfixe réseau pour les réseaux avec peu de machines (tels que ceux de nos domiciles) ; dans ce cas, la « confidentialité » permise serait la même qu'avec l'utilisation d'un NAT sur IPv4.
Pour résoudre les problèmes identifiés, le RFC propose de créer le principe de type d'adresse « temporaire », c'est-à-dire des adresses qui auront l'obligation de passer à un statut obsolète après un certain temps et qui ne seront pas devinables en utilisant des informations disponibles sur le réseau.
Ce RFC précise donc un algorithme qui remplacera l'utilisation de l'adresse MAC pour trouver rapidement un identifiant unique par l'utilisation du hasard. Il conserve les autres principes de l'auto-configuration, mais permet de créer directement un ensemble d'adresses temporaires (au lieu d'une seule adresse) et détermine une période de regénération et remplacement de ces adresses.
Cependant, il a été décidé que, par défaut, la génération des adresses temporaires crée une seule adresse par préfixe réseau pour lequel l’auto-configuration est active. Créer un nombre limité d'adresses évite d'obliger le client à rejoindre trop de groupes multicast (prévus par IPv6 et obligatoires), ce qui permet de ne pas avoir trop d'inquiétudes par rapport aux performances.
L'idée générale de l'algorithme est de tirer un nombre au hasard, de le coller à l'identifiant d'interface existant, d'appliquer une fonction de hashage sur ce nombre (MD5 est proposé, mais l'utilisation d'un autre algorithme est ouvert). Du résultat du hash, on prend les 64 bits les plus à gauche pour les utiliser comme bit d'interface et le reste est conservé comme nombre aléatoire pour la prochaine itération (qui arrivera au moins pour le renouvellement de l'adresse temporaire ou pour le prochain redémarrage de la machine).
Il aurait été possible de ne faire que le tirage de nombre aléatoire, mais il est difficile de trouver un nombre réellement aléatoire. C'est pour ça que l'algorithme a été prévu pour ne le calculer que la première fois et d'utiliser un historique pour générer les nombres suivants.
RFC 7217 : créer par défaut des identifiants d'interface non-prédictibles et stables
Le RFC précédent définit les adresses temporaires pour des communications sortantes, mais elles nécessitent toujours les adresses IP crées avec les adresses MAC pour l'établissement des communications entrantes (fonctionnalités de type serveur).
Le RFC 7217 propose une solution pour rendre plus opaques ces adresses stables nécessaires aux fonctions de type serveur. En effet, l'utilisation de l'adresse MAC permet encore à un attaquant de trouver des corrélations d'activités sur Internet et il peut également plus facilement réduire le nombre d'adresses en cours d'utilisation à scanner (puisque l'adresse MAC réduit le nombre d'identifiants possibles, notamment en connaissant le constructeur des interfaces réseau).
Comme ce RFC travaille sur les adresses stables, il peut être utilisé de manière complémentaire aux adresses temporaires, sans en être dépendant. Ainsi, si un réseau interdit l'usage des adresses temporaires, les risques de découverte d'adresses utilisées et de corrélations d'activité peuvent quand même être réduites.
Dans les grandes lignes, l'algorithme produit des identifiants d'interface stables pour un réseau donné. C'est à dire qu'à chaque changement de réseau, les identifiants changent, mais lors du retour sur un réseau, il devrait reprendre la même valeur qu'auparavant (si l'identifiant n'a pas été utilisé par un autre appareil entre temps). Malgré cette stabilité, les identifiants ne sont pas prédictibles, car l'algorithme utilise une clé privée connue uniquement par le système local.
Ainsi, l'algorithme est capable de créer des identifiants d'interfaces assez stables pour des fonctionnalités de type serveur (connexion entrantes) pour un réseau donné. Il permet d'éviter la corrélation des activités sur différents réseaux (par exemple, l'activité au bureau et à la maison d'une machine portable n'est plus liée par une adresse unique), tout en permettant d'utiliser une adresse non-temporaire pour certains services de la machine.
Conclusion
Finalement, avec l'activation de ces 2 RFCs dans les gestionnaires de réseau des machines, il est possible d'avoir les avantages de l'auto-configuration d'IPv6 avec une protection de la vie privée au moins égale à celle de l'utilisation d'un NAT avec IPv4.
En effet, le RFC 7217 permet de toujours créer des adresses non-prédictibles (et différentes sur chaque réseau) et le RFC 4941 permet de créer des adresses temporaires qui auront l'obligation d'être abandonnées après un certain temps d'utilisation.
Le travail des attaquants est donc rendu bien plus difficile pour créer des corrélations des activités d'une machine sur les réseaux tout en gardant l'avantage d'IPv6 où la configuration manuelle n'est pas nécessaire et où les adresses IPs utilisées sur le réseau sont toutes des adresses publiques facilitant le P2P.
Cette dépêche a été proposée car un développeur de Network Manager a annoncé l'implémentation de ces 2 RFCs pour la release 1.2.
Aller plus loin
- "Network Manager and privacy in the IPv6 Internet" par Lubomir Rintel (297 clics)
- Notes de l'IETF à propos de l'utilisation des adreses MAC comme adresse IP sur Internet (182 clics)
- RFC 4941: Extensions de confidentialité pour l'autoconfiguration IPv6 (171 clics)
- RFC 7217: Méthode de génération d'interfaces opaques avec l'autoconfiguration IPv6 (156 clics)
- RFC 4862 : Autoconfiguration d'adresses IPv6 (144 clics)
- Wikipédia: IPv6 (155 clics)
# Compatibilité du routeur
Posté par Alex G. . Évalué à 5.
Si je devine bien, ces deux choses sont décidé par la machine et il n'y a donc pas besoin d'une implémentation particulière sur le routeur (éléments actifs du réseau hôte) ?
[^] # Re: Compatibilité du routeur
Posté par johan.cb . Évalué à 4.
Oui c'est décidé par ta machine qui génère elle-même ses adresses IPv6 en fonction de l'adresse MAC ou aléatoirement.
[^] # Re: Compatibilité du routeur
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 7. Dernière modification le 15 juillet 2016 à 21:32.
Oui, c'est ça.
Pour la gestion des adresses, le protocole IPv6 prévoit déjà que toutes les adresses utilisées ne sont louées que pour un certain temps. Si je me souviens bien, il n'y a pas vraiment de limite maximale de temps par défaut.
Ici, pour les adresses temporaires, le respect de la RFC requiert juste que la machine connectée déprécie elle-même régulièrement la location de ces adresses et en calcule de nouvelles pour continuer d'utiliser le réseau.
Apparemment, le routeur pourrait avoir un ajustement si le mainteneur du réseau décide de refuser l'utilisation d'adresses temporaires (il faut bien que le routeur bloque le trafic de ses adresses). Sinon, si le mainteneur ne souhaite pas bloquer, il n'y aurait pas besoin d'ajustement.
Pour les adresses stables, c'est juste qu'au lieu d'utiliser uniquement l'adresse MAC pour trouver un identifiant d'interface, la machine doit créer une clé secrète et calculer l'identifiant pour chaque réseau auquel elle se connecte. Donc là non-plus, il n'y a pas besoin d'ajuster la structure du réseau.
C'est ce qui m'a bien motivé pour la dépêche quand j'ai lu l'annonce de Network-Manager: si le réseau IPv6 a été configuré pour que les machines se configurent automatiquement, il suffit d'activer ces options dans Network-Manager pour préserver un peu plus la vie privée des utilisateurs de la machine.
# Typo
Posté par Storm . Évalué à 1.
Une petite typo s'est égarée dans le texte.
Le dernier lien : "Wikipéida: IPv6" -> "Wikipédia : IPv6"
[^] # Re: Typo
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# NAT66 ou masquarade66
Posté par pepie34 . Évalué à 3.
Peut être est-ce la peur du 666 mais je ne comprends pas le conflit religieux qui empêche de faire du NAT66 ou du moins une masquarade 66?
En effet, admettons qu'une routeur serve de passerelle entre les internets et un réseau local et qu'il dispose d'un préfixe sur les internets donnant une grande plage d'ipv6 (par exemple si le nombre ipv6 disponible est très grand devant le nombre de machines réelles). Alors quel dogme l'empêche à chaque connexion sortante de la machine X du réseau local vers les nets de tirer au hasard une IP Y dans sa plage et faire une masquarade de Y vers X le temps de la connexion ? C'est beaucoup plus simple que du NAT44.
[^] # Re: NAT66 ou masquarade66
Posté par SwordArMor (site web personnel) . Évalué à 10.
Parce que le NAT, tout simplement.
Le NAT t’oblige à garder un état de chaque connexion, ce qui n’est pas du tout gratuit en ressources.
Aussi, le NAT suppose de faire un bout de L4 (pour avoir la correspondance des ports UDP et TCP vers telle ou telle machine), alors qu’un routeur ne devrait faire que du L3 (tel bloc d’IP, je le route là, ma route par défaut est là).
De plus, Internet a été conçu en ayant en tête le fait que chaque machine a une IP publique. Avoir des IPs RFC1918 pour aller sur Internet est juste du bricolage pour retarder le passage à l’IPv6 et ça a cassé quelques protocoles au passage. On peut par exemple penser au FTP qui n’est pas du tout trivial à faire marcher avec du NAT ; c’est encore pire dans le cas du FTPS. Si le protocole ne se base pas sur UDP ou TCP, c’est pareil, etc.
Enfin, avoir un NAT66 n’apportera rien par rapport à des adresses temporaires puisqu’elles changerons régulièrement et qu’il sera impossible de tracer quelqu’un avec pour seule information son IP.
Il faut également garder à l’esprit que la plage d’IPv6 est tellement grande qu’il est difficile de tout scanner. Dans un /64 (ce que donne en général un FAI), tu as 72057594037927936 réseaux de 256 IP. Donc rien que pour ton réseau local, tu vas mettre 72057594037927936 fois plus de temps qu’en IPv4.
[^] # Re: NAT66 ou masquarade66
Posté par pepie34 . Évalué à 0.
Dans la proposition chaque IP externe est reliée à une unique IP interne. En quoi çà peut péter le moindre protocole ? On respecte bien une IP pointe vers une seule machine.
L'inverse n'est pas vrai, une IP interne peut est reliée à plusieurs IP externe. Comme on peut tirer 72057594037927936 * 256 IPs on va pas se gêner on peut le faire à chaque nouvelle connexion…, si çà c'est pas de l'obfuscation !
Pour le traçage avec les adresses temporaires cf ma réponse plus bas.
[^] # Re: NAT66 ou masquarade66
Posté par SwordArMor (site web personnel) . Évalué à 2.
Ça peut casser des choses parce que rajouter des couches n’a jamais aidé à rendre les choses simples. En théorie beaucoup de choses sont censées être faisables…
Le NAT66 est effectivement prévu pour faire du 1:1, mais en aucun cas du n:1 (je peux me tromper vu que je n’en ai jamais mis en place, mais ce n’est pas ce que je lis sur https://tools.ietf.org/html/rfc6296). Donc ça supposerait de refaire une spécification du NAT66 pour un cas d’usage déjà couvert par d’autres RFC (comme l’a déjà dit Adrien Dorsaz), puis de développer une implémentation, en prenant en compte le fait que des équipements sont déjà vendus avec une ancienne spécification.
Par contre je peux te dire d’expérience que les deux RFCs citées sont utilisables sans soucis.
[^] # Re: NAT66 ou masquarade66
Posté par haleth . Évalué à 5.
Par exemple, avec le SIP
Dans SIP, au niveau 7, tu as l'information "si tu veux me causer, et tu le veux, puisque c'est un coup de téléphone à double sens, contact moi sur tel IP, tel port"
L'IP et le port en question, c'est mes IP, à moi
Donc, avec du nat, tu dois venir analyser la couche 7, pour dire "oui, alors en fait, non, ne contacte pas cette IP, contacte moi plutôt, et sur tel port s'il te plait"
Et si ton protocole n'est pas dans la liste supportée, ou si le module n'est pas chargé, ou autre, ton truc ne fonctionnera pas
NAT = evil
[^] # Re: NAT66 ou masquarade66
Posté par pepie34 . Évalué à 0.
Voilà donc le diable, on est donc bien dans le registre de la religion !
Pour le coup ce sont les designers du SIP qu il faut pendre ! Le niveau 7 ne devrait jamais s'échanger de manière autonome des informations des niveaux 3/4. La séparation des couches n est pas respectée.
Pour être propre, si tu me contactes et que je veux ouvrir une connexion dans l autre sens je dois récupérer ton IP sur le socket ouvert en local via l os et pas en me fiant aux informations que tu me donnes dans ton contenu applicatif.
(NB en tcp je comprends mal l utilité de la nécessité de connaître l ip de son correspondant comme il y a de base une connexion dans les deux sens ouverte. Peut être en cas de rupture pour que l appelé réinitialise à son initiative la communication ?)
Transmettre deux fois la même information dans deux niveaux différents (l entête IP et le contenu en soit) c est ca le vrai diable. C est comme avoir deux fois la même info dans deux tables différentes d une même BD, on sait qu'un jour tôt ou tard ca va foirer…
[^] # Re: NAT66 ou masquarade66
Posté par claudex . Évalué à 6.
Il va falloir expliquer comment résoudre le cas suivant sans passer par la couche 7. Soit A et B derrière chacun un réseau naté à ta façon. Ils s'enregistrent tous les deux sur le serveur C, ce dernier donne l'IP de A à B et inversement pour qu'ils puissent communiquer. Sauf que l'IP que le serveur C a récupéré de sa socket TCP (ou que A a annoncé à C) ne correspond pas à l'IP qui sera naté de l'autre côté.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: NAT66 ou masquarade66
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Plus le fait qu'en SIP (TCP ou UDP), A peut émettre de ipA:portA, en disant de répondre vers ipA':portA', à destination de B ipB:portB qui demandera d'utiliser ipB':portB', afin de se mettre d'accord sur l'utilisation de ipA":portA" et ipB":portB" pour le média en udp… Et il y des cas plus compliqués.
[^] # Re: NAT66 ou masquarade66
Posté par haleth . Évalué à 0.
Ouais, apprends de quoi tu parles avant de pendre des gens;
L'information qui est envoyé dans SIP n'est pas la même que celle qui est dans les couche 3/4, naturellement.
D'une part parce que tu dois t'y connecter (= cette information indique l'emplacement d'un socket serveur), alors que dans 3/4, j'ai des infos sur un socket client
D'autre part, parce que parfois, tu ne dois pas te connecter à moi, mais à quelqu'un d'autres
C'est comme en HTTP : est-ce débile de mettre des liens href ? Est-ce redondant, vis-à-vis des couches OSI ? C'est vrai que, dans le cas particulier où la ressource est chez moi également, l'information est redondante. Mais in fine, ça ne reste qu'un cas particulier.
Notion de pair à pair, également, je me connecte chez toi, et tu te connectes chez moi (ce qui peut se transformer en "coup à 3" : A -> B, B -> C, C -> A, tout le monde cause avec tout le monde)
Je ne vois pas la relation entre diable et religion.
Que je sache, la notion de bien et de mal n'est pas stricto sensu religieux
La loi te dit ce qui est bien et mal
Ce qui est juste
Ce que tu dois faire, ce que tu ne dois pas faire
La ressemblance est subtile;
[^] # Re: NAT66 ou masquarade66
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 8.
NAT est un protocole qui est utilisé pour pallier au manque d'adresses IPv4 disponible.
En IPv6, tout un chacun pourra utiliser énormément d'adresses, il n'y a donc plus besoin de résoudre ces anciens problèmes.
La question serait plutôt: pourquoi penses-tu avoir absolument besoin de la complexité du NAT ?
Si c'est pour une question de réseau "privé", alors les 2 RFCs de cette dépêche proposent des solutions tout à fait viable qui garantissent la même vie privée qu'avec l'utilisation de NAT.
De plus, leur solution ne complexifie pas la gestion de la structure du réseau, puisque ce sont les appareils du réseau qui les activent.
Si c'est une question de protection contre des attaquants, alors la solution est la configuration d'un Firewall à l'entrée de ton réseau. Il suffit de définir les bonnes règles (interdire par défaut le trafic entrant initié par l'extérieur) et le réseau sera aussi bien protégé qu'en IPv4.
Je ne vois pas bien l'intérêt de cette solution : ça fera juste croire que la machine X a l'adresse Y, mais ça ne changera rien par rapport à la confidentialité et ça demandera plus de travail au routeur (maintient d'une table de correspondance des adresses "réelles" avec les adresses "montrées"). Quel est l'intérêt de ne pas montrer l'adresse "réelle" ?
Ici, les propositions sont que chaque machine du réseau change régulièrement elle-même ses adresses, ça revient au même que ta proposition et ça ne complexifie pas la structure du réseau.
[^] # Re: NAT66 ou masquarade66
Posté par pepie34 . Évalué à 0.
Avec les adresses temporaires il est toujours possible de récupérer de l'information qui était plus difficile à extraire avec du NAT44 comme par exemple le nombre de machines internes. Et à partir du nombre de machines internes, il sera facile de trouver des profiles statistiques de chaque machine et donc de relier une adresse temporaire à une machine précise rien que par son activité. (Pour ceux qui connaissent le clustering, une fois le nombre de clusters connu, le boulot de profilage est quasiment fait)
Pour brouiller cela il faudrait un changement très fréquent des adresses temporaires pour que quelqu'un qui observe la sortie de ton routeur ne puissent pas dire en moyenne je vois x IPs sortir, fréquence de l'ordre de chaque nouvelle connexion TCP/UDP. Hors je ne pense pas que la RFC ait été prévue pour une telle fréquence. Rien que la gestion des collisions d'adresses n'est pas compatible avec cela.
L'idée proposée est bien d'utiliser la TOTALITÉ de la plage disponible en attribuant aléatoirement une IP non-utilisée pour empêcher justement la connaissance du nombre de machines. Cela peut se faire sans trop de ressource par le routeur, un générateur de nombre aléatoire suffit (la probabilité que le générateur sorte 2 fois la même IP sur deux connexions sortantes en cours est extrêmement faible ), pas de gestion de collisions à se soucier car seul le routeur attribue les IPs externe. En outre, la mascarade en elle même est bien plus simple que du NAT44, une simple table où chaque ligne contient 2 IPs suffit (l'IP externe et l'IP interne), le nombre de ligne est à fixer en fonction du nombre de connexions simultanées max acceptables par le routeur. Pas besoin de regarder les ports, pas besoin de suivre les connexions…c'est peanuts par rapport au travail d'un NAT44.
[^] # Re: NAT66 ou masquarade66
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 3.
Désolé, mais je ne vois pas comment on retrouve le nombre de machines internes par les adresses temporaires utilisées. Toutes les machines ne se connectent pas en même temps sur Internet et n'ont pas une connexion permanente.
Qu'est-ce qui peut te confirmer ou infirmer que l'adresse X utilisée il y a 3 minutes appartient à la même machine que l'adresse Y utlisée actuellement ? Si tu arrives à me répondre, alors il faut proposer une correction de la RFC, car l'algorithme prévoit que la prochaine adresse utilisée ne peut pas être devinable par quelqu'un d'extérieur.
Pour la mascarade, je ne comprends toujours pas quelles sont les avantages d'avoir des adresses internes et externes ? Que cherches-tu à cacher / protéger ?
Comment penses-tu que les outils de P2P fonctionnent actuellement si la machine était vraiment "cachée" par une mascarade ?
Évidemment, puisque l'on ne serait plus dans le cas d'un réseau auto-configuré. Ces 2 RFCs ne traitent que des cas de réseaux IPv6 auto-configurés (avec un préfixe réseau suffisamment petit).
Ce que tu décris là, n'est pas une configuration de routeur, mais un serveur DHCPv6, si j'ai bien compris. Ça ne nécessite quand même pas de NAT et de mascarade pour pouvoir fonctionner, mais ça demande plus de travail sur la structure du réseau.
[^] # Re: NAT66 ou masquarade66
Posté par pepie34 . Évalué à 2.
1) Je crois qu'il y a quiproquo
Dans la proposition le routeur ne s'occupe jamais de la façon dont les machines internes s'attribuent les adresses IP. Cela n'a rien n'a voir avec du DHCPv6.
Le routeur voit passer un paquet qui va de "A vers B" où A est sur son interface interne et B est sur son interface externe, il change l'entête pour "X vers B" où X est dans sa plage de dispo. Il garde en mémoire la correspondance (A,X) et quand un paquet arrive de "C vers X" où C est sur son interface externe alors il change l'entête pour "C vers A". Noter que B et C ne sont pas forcément supposés identiques.
Le routeur n'a rien à faire de comment A est devenu a eu l'IP A.
2) Je crois qu'il y a encore plus quiproquo
Comme indiqué plus haut X ne correspond qu'à une seule machine interne donc çà pète pas les protocoles même le P2P. Tant qu'il y a suffisamment de place dans la table de correspondance, le routeur peut toujours retrouver qui est X même trois jours plus tard.
3) Ce qu'on cherche à cacher: le profil d'activité des machines !
En utilisation stationnaire, une machine est facilement reconnaissable à son profile statistique d'activités, peu importe son IP à l'instant t. Je n'ai pas besoin de savoir de façon déterministe comment elle passe de l'IP X à l'IP Y pour savoir que X et Y sont la même machine. Çà n'a rien à voir donc avec la RFC et comment les IP sont attribuées (aléa ou pas aléa).
Répartir les activités (à la connexion) sur toutes les IPs dispos, çà rend une attaque statistique difficile.
[^] # Re: NAT66 ou masquarade66
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 3.
Merci, on est bien d'accord sur le fonctionnement d'un routeur (même d'un switch en fait).
Je ne comprends vraiment pas ce qu'apporte de plus un NAT66 à la place des adresses temporaires.
La seule différence que je vois est que la table de correspondances du NAT serait publique à un certain moment avec les adresses temporaires.
Si tu souhaites absolument garder cette confidentialité du NAT, pourquoi ne pas faire plus simplement du NAT64 ?
Ça impliquera des tables de correspondances beaucoup plus petites que du NAT66. De toute façon, si tu souhaites "cacher" ton réseau derrière un NAT autant garder une structure réseau IPv4, puisque les avantages de l'IPv6 seront perdues (plusieurs adresses IP atteignables de l'extérieur du réseau par machine).
[^] # Re: NAT66 ou masquarade66
Posté par pepie34 . Évalué à 0. Dernière modification le 17 juillet 2016 à 00:12.
Jamais la table de correspondance est publique !
Cette phrase est la preuve que tu n as pas compris la proposition. Le principe du end to end de l ipv6 est bien maintenu.
Je vais reformuler de deux nouvelles façons:
1. Il s'agit de faire du Network prefix translation avec en plus de l obfuscation du suffixe.
2. Dans du nat44 il y a 1 ip publique avec n ip locales. Dans la proposition ici c est l inverse, il y a m ip publiques pour n ip locales avec m très grand devant n.
Pour reproduire un comportement similaire avec les adresses temporaires telles que proposées par la RFC, il faudrait que la machine tire une nouvelle adresse temporaire très fréquemment et avec plusieurs ip temporaires en parallèles par exemple pour chaque connexion en cours. Cependant, je ne pense pas que les mécanismes proposés puissent tenir un tel rythme.
[^] # Re: NAT66 ou masquarade66
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 4.
Le end to end ne peux pas être maintenu avec des NATs: il faut pouvoir répondre au cas d'usage du commentaire de Xavier Claude, plus haut.
Le NAT44 permet aussi de faire de la correspondance m à n, mais l'usage est d'avoir m=1 (car le problème résolu avec NAT est le nombre d'adresses disponibles).
Le NAT64 permet de réduire la taille du n de manière plus raisonnable, puisque tu souhaites cacher ton réseau interne et surtout que le principal avantage de l'IPv6 n'est pas maintenu (le end to end).
La RFC propose en effet que la durée d'utilisation de l'adresse temporaire par la machine soit de 1 jour, mais c'est configurable.
Je pense que l'on se bat contre une chimère : vouloir des connexions end to end avec de la confidentialité de la structure réseau à chaque point. De plus, une écoute active du réseau permettra toujours de pouvoir tirer des informations avec les statistiques avec plus ou moins d'incertitudes.
Ce qui me plaît avec ces RFCs, c'est que ça garde possible l'utilisation du end to end tout en améliorant la confidentialité des activités de la machine à postériori. La RFC propose de créer des plages d'adresse temporaire, donc les logs du serveur X générés par le client A à l'instant T peuvent être différents des logs du serveur Z au même instant T. Ça dépend uniquement de la gestion des adresses par le client et c'est déjà disponible en pratique.
# Modification de l'ethernet automatique
Posté par reminimir . Évalué à 7.
Si je comprend bien, après vérification je suis sous Ubuntu-mate 16.04 lts et effectivement Network-manager est en version 1.2.0
je suis en ipv6
il suffit de régler network manager dans ipv6 sur extension de confidentialité: adresse temporaire:
C'est tout?
[^] # Re: Modification de l'ethernet automatique
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 2.
Pour l'interface graphique, je ne suis pas sûr.
Dans l'article, ils parlent des paramètres
ipv6.ip6-privacy, pour les adresses temporaires (je pense que la capture d'écran correspond à ça), etipv6.addr-gen-mode, pour les adresses stables opaques avec la valeurstable-privacy.Pour être sûr, j'ai regardé sur ma Debian dans le dossier
/etc/NetworkManager/system-connectionset j'ai trouvé cette section dans le fichier de configuration de mon réseau:[^] # Re: Modification de l'ethernet automatique
Posté par reminimir . Évalué à 1.
chez moi j'ai ça:
[ipv6]
addr-gen-mode=eui64
dns-search=
ip6-privacy=2
method=auto
si je choisi adresse publique préférée, j'ai:
[ipv6]
addr-gen-mode=eui64
dns-search=
ip6-privacy=1
method=auto
si je désactive:
[ipv6]
addr-gen-mode=eui64
dns-search=
ip6-privacy=0
method=auto
# Internet != Web
Posté par RyDroid . Évalué à 4.
Je suppose que l'adresse globale sert à se connecter au reste d'Internet et non seulement du Web. Si non, pourquoi ne pas avoir une adresse globale par service ?
[^] # Re: Internet != Web
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 2.
Oui, c'est bien une erreur qui s'est glissée. Je voulais bien dire au reste d'Internet.
[^] # Re: Internet != Web
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# Travail, maison
Posté par SwordArMor (site web personnel) . Évalué à 6.
Que ce soit en IPv4 avec des adresses publiques, en IPv4 avec du NAT, ou avec de l’IPv6, on peut très facilement savoir si quelqu’un est chez lui ou au boulot.
Chez moi je sors avec des IPs (v4 et v6) grifon, en cours avec des IPs (v4 et v6) renater, et au boulot avec de l’IPv4 SFR. Si on sait utiliser un moteur de recherche pour le premier FAI et son cerveau pour le reste, il est facile de savoir où je suis, et quand.
Si on veut vraiment se protéger de ce genre d’attaque, la seule solution est de toujours utiliser un VPN. Et que le VPN fournisse que du v4, que du v6 ou de l’IPv4 et de l’IPv6, ça ne change rien non plus.
# Hors sujet
Posté par Philippe Martin . Évalué à 5.
Désolé c'est un peu hors sujet mais on parle tellement peu d'IPv6 en général que c'est pas facile de coller au sujet :
le hic pour moi avec ce passage de IPv4 à IPv6, c'est que tant qu'IPv4 marche bien, je ne me se soucie pas trop de savoir si IPv6 est bien configuré sur mes machines.
Est-ce que quelqu'un parmi vous a déjà configuré son poste de travail en IPv6-only sur une longue durée, et si oui a-t-il pu utiliser ses différents services sur l'internet ?
Ce serait un bon moyen ÀMHA que chacun se rende compte réellement des lacunes qu'il reste à combler dans nos configs IPv6 (je parle principalement pour ceux qui montent des services sur l'internet, genre sites web).
[^] # Re: Hors sujet
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 5.
Hello,
J'ai les 2 protocoles sur mon réseau et j'utilise l'extension Firefox SixOrNot pour avoir une petite idée de ce qui est disponible en IPv6.
Personne ici ne pourra répondre à ta question s'il est effectivement en IPv6 seulement: LinuxFR n'est connecté qu'à IPv4 ;)
Sinon, Google, Facebook et quelques autres gros sites sont disponible en IPv6, mais Github, par exemple, n'est disponible que en IPv4 (alors que Gravatar est disponible en IPv6).
Au niveau des services webs, c'est très disparate. Il faudrait déjà que les hébergeurs proposent des hébergements connectés aux 2 réseaux avant que ce soit utile (SixXS tient une liste des hébergeurs IPv6) et que les fournisseurs de strcutures de type "cloud" soient également compatibles.
Google tient des statistiques sur l'utilisation d'IPv6 par leurs visiteurs, ça à l'aire déjà de bien progresser de leur côté (depuis janvier, on est passé de 4% du trafic à 10% environ).
[^] # Re: Hors sujet
Posté par Philippe Martin . Évalué à 1.
Super, merci pour cet état des lieux. Bon, il va falloir que je ressorte un Nagios pour tester ces services sur ipv6 proprement. Ou en profiter pour tester Shinken :)
[^] # Re: Hors sujet
Posté par rogo . Évalué à 3.
Si tu as parfois des comportements bizarre de tes machines, il faudra regarder du côté d'IPv6, parce qu'avoir un truc mal configuré mais actif, ça peut poser des problèmes de stabilité et de sécurité.
Un exemple : on avait un VPS dont le postfix essuyait parfois des refus. La plupart des emails partaient bien, mais de temps à autre, quelques uns nous étaient retournés. Quand on testait, tout allait bien. Un jour un refus a été motivé de façon plus claire, et on a compris que Postfix utilisait parfois IPv6. Or notre config, notamment DNS, était écrite pour de l'IPv4 seulement.
[^] # Re: Hors sujet
Posté par SRL . Évalué à 1.
En tout cas, en France ça bouge. Apparemment, Orange commence enfin à attribuer des préfixes IPv6 /56. Pour le moment, ça se limite uniquement aux quelques élus fibre/VDSL. Les clients ADSL doivent patienter pendant le déploiement progressif jusqu'à 2017 maximum. À priori, d'ici 2018, une grosse partie des internautes Français seront en dual stack.
Tu peux faire de l'IPv6 only avec les VPS de chez Gandi. L'absence d'IPv4 fait économiser ~5€/mois.
J'espère que cette démarche sera également adopté par OVH et online.net. Ça permettra de pousser Free et SFR (et Orange ?) d'activer par défaut l'attribution de préfixes IPv6 à leurs clients.
[^] # Re: Hors sujet
Posté par Meku (site web personnel) . Évalué à 3.
Je suis un peu pareil que toi, je ne m'en suis pas encore préoccupé…
Alors pour mon expérience perso : j'utilise Ubuntu et mon FAI est Orange (VDSL). Il se trouve que ma box fournit à mon PC à la fois une adresse IPv4 et une adresse IPv6 sans que je ne fasse rien.
Un jour, pour une raison inconnue, ma box ne m'a distribué qu'une adresse IPv6. L'expérience a été un peu étrange, puisque certain sites web fonctionnaient (Wikipedia, google) et d'autres non. Au début, j'ai pensé à un problème de serveur… puis ça faisait beaucoup de serveurs à problème quand même :p
Alors j'ai grogné un petit peu sur le DNS de Orange, mais en changeant par le DNS google c'était pas mieux… J'ai fini par m'apercevoir que je n'avais pas d'IPv4.
Bref, il semblerait que l'IPv6 commence à fonctionner localement « out of the box », par contre sur l'internet, tout le monde n'est pas encore prêt. Je ne peux pas vraiment répondre à ta question sur la « longue durée », car j'ai pas tenu plus de 5 minutes dans cette configuration, rien que pour le web.
# IPv6 fixe local avec IPv6 temporaire internet
Posté par EauFroide . Évalué à 2. Dernière modification le 21 juillet 2016 à 21:51.
Peut-on coupler une IPv6 fixe sur le réseau local avec une IPv6 temporaire/dynamique pour les communications internet?
Par exemple j'ai un service web accessible depuis internet à travers un reverse proxy apache2 (qui a besoin d'une ip fixe*1) et directement via Tor Hidden Service (pour qui une IPv6 dynamique serait un meilleur gage de sécu*2)
*1 ou d'un hostname si routeur compatible hairpinning
*2 note que je sais pas si tor est compatible IPv6
PS: merci pour la dépêche intéressante :)
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: IPv6 fixe local avec IPv6 temporaire internet
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 22 juillet 2016 à 13:04.
Tiens, je ne sais pas si l'auto-configuration IPv6 exclue la configuration statique de certaines adresses, mais je pense que les deux peuvent être utilisés sur une même machine (en tout cas, la configuration automatique et DHCPv6 sont clairement indiqués comme complémentaires dans l'introduction de la RFC 4862).
Par contre, il faut bien comprendre avec IPv6 qu'il n'y a plus de nécessité d'avoir un réseau local entre les machines d'un même réseau. Comme elles ont toutes leurs propres adresses publiques, autant utiliser celles-ci directement.
Il existe bien le réseau local avec le préfixe
fe80::pour pouvoir débuter les communications entre le routeur et les membres du réseau et il peut être utilisé pour communiquer entre membres du réseau, mais je ne pense pas qu'il apporte plus d'avantages que le réseau publique.Pour protéger les machines du réseau, c'est un firewall qu'il faudra configurer correctement afin de ne pas exposer directement toutes les machines directement sur Internet.
Dans ce cas, les RFCs de cette dépêche gardent le concept d'adresses IP stables pour les fonctionnalités de type serveur.
Typiquement, apache2 n'écoutera pas les adresses IP temporaires, mais uniquement les adresses stables.
La première RFC indique bein que c'est pour les communications sortantes qu'il faut utiliser de préférence les adresses temporaires
L'idée de la seconde RFC de la dépêche est de dissimuler un peu plus les adresses stables: au lieu de restreindre les suffixes à l'utilisation de la plage d'adresses MAC, la RFC propose d'utiliser toute la plage disponible (tout en gardant cette adresse stable sur le réseau). Ainsi, un attaquant qui voudrait trouver les fonctionnalités serveurs d'un réseau devra scanner une plus grande plage d'adresse IP (ou passer par un autre moyen).
Pour Tor, je ne connais ce réseau que de nom, mais il faudrait pouvoir avertir dynamiquement le service Tor quand les adresses IPs actuelles vont devenir obsolètes et transmettre les nouvelles adresses IPs lors de leur création.
Merci aussi à la communauté LinuxFR de m'avoir relancé 2-3 fois pour la terminer :) Ça faisait 6 mois qu'elle traînait dans l'espace de rédaction ^^
# Non, on ne protége pas plus sa vie privée avec IPv6 ... même le contraire !
Posté par ledufakademy . Évalué à -7.
En Ipv4 by design on doit NATé etc, ce qui constitue déjà un masquage de réseau.
En IPv6 de l'ordi. à la simple montre connecté l'adresse est … "publique" et "local" .
Faut arrêter de vendre du vent.
Les Chinois seront peut-être emmerdés avec la pénurie d'adresse , pas en france où FT dispose d'un stock LARGEMENT suffisant !
# Chez soi derrière sa Box, comment faire ?
Posté par Yves (site web personnel) . Évalué à 3.
Un truc m’échappe au sujet d’IPv6. Pour l’utilisateur lambda, qui branche insouciamment n’importe quel équipement derrière sa Box Internet, se sachant « protégé » (plus ou moins…) par le NAT de la Box, quel est la conséquence du passage à IPv6 ?
La console de jeux, l’appareil photo, la webcam, l’imprimante, le PC portable fraîchement installé, etc. (je n’ai pas tout ça ; ce sont des exemples !) se retrouvent tout à coup en prise directe avec Internet, non ?
Que faire alors ? Chaque équipement doit-il être sécurisé indépendamment, ou bien la Box permet-elle par défaut, par exemple, de laisser passer les connexions IPv6 sortantes, sans autoriser aucune connexion entrante (sauf celles explicitement autorisées ; pour du self-hosting par exemple) ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.