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. Un
futur RFC décrira
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.
