Mon blog

L'ICN est l'idée (très contestable) qu'un réseau informatique sert à accéder à du « contenu » et que le réseau doit donc être architecturé autour de cette idée de contenu. Les noms identifient ainsi un contenu donné. Mais il faut bien ensuite trouver le contenu donc résoudre ces noms en quelque chose de plus concret. Ce RFC est le cahier des charges d'un tel système de résolution de noms pour les projets ICN. Comme beaucoup de cahier des charges, il est très « liste au Père Noël », accumulant des desiderata sans se demander s'ils sont réalistes (et compatibles entre eux !).

Comme avec beaucoup de documents qui promeuvent l'ICN, ce RFC donne une description erronée du nommage et de l'adressage dans l'Internet d'aujourd'hui. Passons, et voyons ce que l'ICN propose. L'idée est que le contenu est stocké dans des NDO (Named Data Objects) et que toute activité dans le réseau coniste à récupérer des NDO. Les NDO sont identifiés par un nom. Il ne s'agit pas seulement d'un identificateur mis au-dessus d'un réseau architecturé sur d'autres concepts (comme le sont les URI) mais du concept de base du réseau ; les routeurs ne routent plus selon des adresses mais selon les noms des NDO. Le problème est évidemment qu'il faudra bien, à la fin, trouver l'objet désiré. Cela nécessite (cf. RFC 7927) :

• Un mécanisme de résolution des noms en de l'information plus concrète (une localisation, un autre nom, etc),
• un mécanisme de routage vers l'endroit où se trouve le NDO,
• un mécanisme de récupération du NDO.

Ce RFC se focalise sur le premier point, le NRS (Name Resolution Service), et en est le cahier des charges. Le RFC 9236 a depuis décrit l'architecture envisagée. Si vous voulez apprendre des choses sur les ICN en général et la résolution de noms en particulier, voir par exemple « A Survey of Information-Centric Networking » ou « A Survey of Information-Centric Networking Research ».

Si on compare avec l'Internet actuel, le NRS aura un rôle analogue à celui de BGP (plutôt que du DNS, car le NRS sera au cœur du réseau, et complètement inséparable). Bon, ceci dit, c'est plus compliqué que cela car, derrière l'étiquette « ICN », il y a des tas de propositions différentes. Par exemple, certaines ressemblent plutôt à l'Internet actuel, avec une résolution de noms en localisateurs qui servent ensuite pour le routage (comme dans IDnet, cf. « IDNet: Beyond All-IP Network), alors que d'autres versions du concept d'ICN utilisent les noms pour le routage (comme le NDN ou le CCNx du RFC 8569). La section 2.4 du RFC compare ces approches.

La section 3 du RFC est ensuite le cahier des charges proprement dit. Malheureusement, elle plane au-dessus des réalités quand elle affirme par exemple qu'il faut un NRS qui fonctionnera de la même façon que l'espace de nommage soit plat ou hiérarchique. C'est très irréaliste, il n'y a pas de nette séparation entre la structure de l'espace de nommage et le mécanisme de résolution. Ainsi, ce mécanisme, dans le cas du DNS, est très lié à la structure des noms. Si on la change, tout le DNS serait à refaire (et sans doute en moins efficace). Parmi les systèmes d'ICN qui utilisent un nommage hiérarchique (et réintroduisent donc une forme de « localisation » dans les noms), on trouve NDN et CCNx.

Certains des mécanismes de résolution discutés ont déjà un RFC, par exemple le NI du RFC 6920, utilisé dans NetInf (cf. « Network of Information (NetInf) - An information-centric networking architecture »).

Bref, les principes du NRS :

• Fonctionner avec des structures d'espaces de noms différentes (cf. ma critique ci-dessus),
• accepter la mobilité des contenus,
• passer à l'échelle (ce qui est trivial avec des noms hiérarchiques, beaucoup moins avec des noms plats),
• permettre la mémorisation (caching),
• accepter que les objets soient identifiés par un nom choisi ou par un condensat du contenu (ce que le RFC nomme les « objets sans nom », ce qui me semble accroitre encore la confusion),
• permettre enfin de récupérer des métadonnées et pas seulement le localisateur.

Et le cahier des charges à proprement parler est en section 4. Je ne cite pas tout mais la liste au Père Noël comprend :

• Des réponses rapides (« en un temps raisonnable »),
• des réponses correctes (on voit bien le ridicule de l'approche par cahier des charges, quand il faut préciser explicitement des points aussi évidents), et à jour (là encore, « raisonnablement »),
• des réponses justes, respectant un principe de neutralité (pas de censure ? L'ARCOM n'aimerait pas),
• un fonctionnement satisfaisant sur des réseaux de grande taille (le RFC mentionne au moins 10^21 objets),
• un système gérable (pouvant s'adapter avec par exemple l'ajout et le retrait de nœuds),
• la capacité à être réellement déployé (là encore, on a envie de dire « encore heureux »),
• la résistance aux pannes (la panne d'une machine ne doit pas arrêter le NRS), et aux attaques par déni de service,
• la confidentialité des requêtes (un problème pour le DNS, cf. RFC 7626), mais aussi des données (le RFC mentionne des ACL sur les noms, chose qui n'existe pas vraiment dans le DNS)
• l'authentification des serveurs, des producteurs de noms (par exemple pour que seule l'entité qui a enregistré un nom puisse modifier les données associées), et des données elle-mêmes (ce que DNSSEC fournit au DNS),

Une conclusion ? Les projets regroupés sous le nom d'ICN sont assez anciens, n'ont rien fait de vraiment nouveau récemment, et il y a peu de chances que ce RFC soit suivi de réalisations concrètes.