Le draft sur IPV8 plusieurs idées intéressantes ...

Introduction : la proposition de James Thain concernant l’IPV8

Au cours de ma veille technologique, j’ai récemment découvert la proposition de James Thain concernant l’IPV8. La lecture de la version 2 du draft permet d’avoir une vision globale de l’auteur et de la philosophie qui entoure IPV8.

Bien que cette initiative puisse paraître intéressante à première vue, elle soulève néanmoins des questions fondamentales et des préoccupations majeures. En effet, un tel concept semble entrer en contradiction avec les principes mêmes de l’Internet, qui doit impérativement demeurer une infrastructure décentralisée et exempte de tout point simplifiant son exploitation.

Dans ce billet, je n’entrerai pas dans le détail de toutes les propositions d’IPV8. Mon objectif est plutôt d’apporter une réflexion et de soulever quelques observations purement sécuritaires concernant la centralisation des fonctionnalités qu’il implique et en particulier de l’utilisation d’un serveur de zone IPV8.

Le serveur de zone IPV8

Selon les sections du draft (1.3 à 1.5), la philosophie de zone repose sur une zone unique, authentifiant et distribuant les adresses IPV8 au sein de sa zone, en maintenant les informations de routage pour cette zone.

👉 Cette zone server concentre un très grand nombre de fonctions qui simplifie potentiellement l’exploitation d’un réseau IPV8.

1. L’attribution des adresses (DHCP8);
2. La résolution de noms (DNS8);
3. La synchronisation temporelle (NTP8);
4. La collecte de télémétrie (NetLog8);
5. le cache d’authentification (OAuth8);
6. la validation des routes (WHOIS8);
7. L’application des listes de contrôle d’accès (ACL8);
8. la traduction entre IPv4 et IPv8 (XLATE8).

Sécurité Est-Ouest et Nord-Sud

La sécurité Est-Ouest et Nord-Sud repose sur le concept d’une défense en profondeur (ACL8, DNS8/XLATE8, WHOIS8), qui permet de valider la légitimité,qui a le droit de parler à qui en utilisant quelle route, mais cette approche ne permet pas de valider le contenu du flux ou le comportement en lien avec celui-ci.

👉 Finalement, la défense en profondeur et la segmentation réseau réduit la surface d’attaque concernant principalement le mouvement latéral, mais ne remplace pas la nécessité de sécuriser l’identité qui consomme les flux réseau.

Scénarios probables

Même si la proposition de James Thain est intéressante et ambitieuse celle-ci présente quelques angles morts qui permettent potentiellement d’exploiter une infrastructure de type IPV8.

Scénario #1 : Que se passe-t-il dans le cas où un poste de travail et l’identité rattachée à celui-ci dans une zone étaient compromis et que l’attaquant encode les données qu’il souhaite voler dans un flux légitime ?

Si aucune règle ne regarde le contenu du flux, avec seulement la validation source, destination, une exfiltration via la passerelle de service légitime (Est-Ouest) est possible n’est-ce pas ?

Scénario #2 : Que se passe-t-il si un ASN est lui-même compromis ?

Il est envisageable que les mécanismes natifs d’IPV8 autorisent un flux légitime (Nord-Sud), en direction d’un C2 hébergé chez cet ASN compromis, n’est-ce pas?

Scénario #3 : Que se passe t-il si la zone serveur est compromise ?

Il est probable que l’agent malicieux puisse rdiriger des flux réseau vers des systèmes qui sont sous son contrôle, d’usurper des identité, Etc.

Conclusion

Dans les deux premiers scénarios, le système respecte le fonctionnement des différents contrôles d’IPV8 qui sont basés sur l’isolation, la légitimité des services infonuagiques et non sur l’identité.

Puisque les contrôles d’IPV8 n’encadrent pas la détection d’abu d’une autorisation légitimement acquise et qu’IPV8 centralise un très grand nombre de fonctions critiques via le serveur de zone, cet état de fait induit un point d’entrée simplifiant son exploitation et le non-respect de la philosophie de l’internet qui doit être décentralisé.

Le scénario #3 est à mon sens, le plus critique dans l’architecture IPv8 telle qu’elle est décrite dans les drafts actuels.

Est-ce que l’Internet Engineering Task Force (IETF) va normaliser la proposition de James Thain via une nouvelle RFC, tel quel j’en doute fortement. Il est néanmoins important de reconnaître l’excellent travail réalisé par James Thain, concernant ce draft sur IPV8, qui démontre une volonté de faire avancer notre domaine.

J’aimerais connaître le point de vue des professionnels et passionnés du domaine, au plaisir de lire vos réflexions !