Ce nouveau RFC, issu de
l'IRTF et donc assez futuriste, se penche sur
les « réseaux autonomes » (autonomic networking),
c'est-à-dire sur les réseaux qui se débrouillent tout seuls, sans
administrateur réseaux, sans
DSI, sans ICANN, etc. Un
réseau autonome doit se configurer, s'optimiser, guérir des pannes et
se protéger des attaques sans intervention humaine. Ce RFC n'explique
pas comment les réaliser (c'est le début d'un programme de recherche)
mais définit la terminologie et les buts à atteindre. Il a été publié
en même temps que le RFC 7576, qui analysait
les techniques existantes et leurs limites. (Le groupe de travail IETF
ANIMA travaille sur les aspects plus concrets de ce sujet.)
La première description de tels réseaux autonomes date de 2001
(l'article
de Kephart et Chess). L'idée est que toutes les boucles de régulation du
système doivent être fermées, sans interaction avec l'extérieur (d'où
l'adjectif « autonome »). IP lui-même a éte
partiellement conçu pour fonctionner ainsi (la fameuse demi-légende de
l'Internet prévu pour résister à une attaque
nucléaire). Un protocole comme OSPF est
autonome dans la mesure où il s'adapte tout seul aux changements de
topologie. Toutefois, IP n'a jamais été complètement autonome et les
évolutions qu'il a subi allaient plutôt dans le sens de mettre plus
d'intelligence dans la configuration externe que dans le réseau
lui-même. Est-ce grave ? Pour un grand réseau d'un
Tier 1, on peut penser que son propriétaire
préfère que le réseau n'ait pas trop d'autonomie
(Skynet ?) et suive plutôt la politique
configurée. Mais les réseaux autonomes sont tentants pour
l'Internet des objets, quand on a un grand
nombre de petites machines très simples, ensemble qui serait très
difficile ou impossible à configurer avec les outils existants. Notre
RFC estime que les deux approches (configuration extérieure
centralisée, et fonctionnement réparti autonome) ont leurs avantages
et inconvénients, et que pas mal de réseaux utiliseront une de ces
deux approches pour certaines fonctions et la seconde pour les autres
fonctions. Ne cherchez donc pas de réseau complètement autonome tout
de suite.
De toute façon, l'approche autonome ne peut pas tout faire. Elle
nécessite de découvrir tout seul un certain nombre de choses et
la politique de gestion du réseau (qui peut s'en servir, pour quoi...)
est un bon exemple de quelque chose qui ne peut pas être découvert,
qui doit être configuré explicitement.
Les réseaux autonomes ont fait l'objet d'un très grand nombre
d'études scientifiques et de publications (la section 7 du RFC
contient des lectures, pour les gourmands, notamment trois synthèses
de l'existant). Attention, on dit « autonome » et pas
« automatique ». Il faut se gérer seul, pas juste dérouler
automatiquement un script pré-établi par un humain (voir la section 2 sur les définitions). Par exemple, un système
automatique doit être reprogrammé lorsque l'environnement change alors
qu'on attend d'un réseau autonome qu'il s'adapte seul.
Donc, que veut-on d'un réseau autonome ? La section 3 décrit les
buts. Le réseau doit être auto-géré ce qui se décline en :
- Se configure tout seul. Les machines démarrent, se découvrent,
trouvent les liens qui les relient et se mettent à les utiliser. Pas
d'admin' pour avoir tapé des
default_router=fe80::1.
- Se guérit tout seul. Une pelleteuse arrache un câble ? Le réseau
contourne le problème automatiquement (ceci marche dans l'Internet
actuel : rappelez-vous qu'on a déjà certaines fonctions qui peuvent
marcher de manière autonome).
- S'optimise tout seul en trouvant la meilleure façon d'accomplir
les tâches définies.
- Se protège tout seul car le monde est hostile et cruel et des
hackers chinois islamistes à cagoule vont attaquer le réseau.
Évidemment, en trichant, on peut définir tout réseau comme
« autonome » si on élargit la définition pour inclure, par exemple, un
contrôleur central (comme avec le SDN). Le RFC
est donc plus spécifique : « tout seul » veut dire « en n'utilisant
que des fonctions qui sont sur les machines terminales ». Comme dit
l'Internationale, le réseau autonome n'a « ni
Dieu, ni César, ni tribun[, ni contrôleur SDN] ».
Comme on ne peut pas envisager un Internet complètement autonome,
ces réseaux autonomes vont devoir coexister avec les méthodes de
gestion traditionnelles (comme Netconf). Cela
peut nécessiter un mécanisme d'arbitrage si les deux méthodes sont en
désaccord. Le RFC utilise un exemple tiré de l'aviation : un avion où
le pilote automatique se coupe automatiquement
si le vol sort d'une certaine plage de paramètres (par exemple si
l'angle d'incidence est trop élevé). Toutefois,
on peut aussi se dire qu'une crise n'est pas le meilleur moment pour
passer brutalement le contrôle au pilote stressé et le RFC demande donc que
les mécanismes autonomes ne se coupent pas tout seuls, même dans des
situations non prévues.
Autre but de nos réseaux autonomes : qu'ils soient sûrs. On doit
pouvoir, par exemple, empêcher un intrus de rejoindre le réseau, ce
qui implique un certain mécanisme d'authentification, qui ne sera pas
forcément totalement autonome (par exemple un
certificat émis par une
AC, une base d'utilisateurs centralisée, etc). Bref, il faudra sans doute de la
cryptographie.
« Autonome » ne veut pas dire « isolé et sourd-muet » (sinon, ce ne
serait pas un réseau). La machine doit communiquer avec des pairs mais
aussi avec des autorités, comme cela qui lui communique le travail à
faire, à qui la machine terminale transmet des rapports, des
statistiques, etc. C'est ce qu'on nomme l'interface Nord (car placée en haut sur
les schémas et tant
pis pour l'Australie).
On a vu que le réseau n'est pas créé pour satisfaire les machines
mais pour accomplir un certain travail. Il faudra donc un mécanisme
pour informer les machines de ce travail, et des changements dans les
définitions de ce travail. Ce mécanisme doit être de haut niveau,
sinon, ce ne sera plus un réseau autonome, on retournerait à la
configuration centralisée traditionnelle. Par exemple, le RFC demande
que ce mécanisme n'expose pas la version d'IP utilisée
(IPv4 ou IPv6) : cela
doit rester un détail technique interne au réseau.
J'ai parlé plus haut de transmettre des rapports à l'autorité
centrale. Il est évidemment nécessaire de prévenir les humains qui ont
acheté et déployé ces machines de l'efficacité de celles-ci : le
travail a-t-il été fait ? Mais, pour respecter le principe d'un réseau
autonome, les rapports ne doivent pas porter sur des détails
d'implémentation que le réseau doit résoudre lui-même (comme « le lien
entre la machine X et la machine Y ne marche plus »). Il faut au
contraire un mécanisme de communication abstraite, synthétisant
l'information, pour ne pas écrouler l'autorité centrale sous les
détails. Imaginons que l'autorité ait envoyé le but de haut niveau
« économise l'énergie », le rapport devrait être du genre « 30 % de réduction
de la consommation, obtenu en éteignant 40 % des ports réseau ». Pour
résumer : les rapports devraient décrire le réseau globalement, pas
machine par machine ou lien par lien.
Le RFC 7576 montre qu'il existe déjà un
certain nombre de protocoles et de fonctions autonomes dans la famille
IP. Mais le but du projet « réseaux autonomes »
n'est pas uniquement d'empiler des solutions mais de les intégrer dans
un cadre commun, qui reste à développer.
Enfin, « autonome » est un adjectif qu'on peut appliquer à toutes
les couches. Par exemple, les
commutateurs typiques aujourd'hui sont
autonomes au niveau 2 (on les branche n'importe comment et ils font une topologie
qui marche). Les routeurs peuvent en faire autant au
niveau 3, comme vu avec
l'exemple OSPF.
Un bon cahier des charges doit aussi avoir des non-buts : ce qu'on
ne cherche pas à atteindre. C'est le rôle de la section 4 du RFC. Les
non-buts sont :
- Supprimer complètement tout opérateur humain (Skynet,
encore). Les humains vont rester, mais en se concentrant sur des
fonctions de haut niveau, comme la définition et la vérification des politiques.
- Résoudre tous les problèmes. De temps en temps, il se produira
un évènement dont le réseau ne saura pas se dépêtrer seul. Là encore,
des humains devront intervenir. Ce sera au moins le cas pour les
pannes matérielles, tant que les ordinateurs n'auront pas de
périphériques leur permettant d'aller à la casse eux-même...
- Supprimer tout contrôle central. Comme le note le RFC,
la Direction Générale ne serait sans doute pas d'accord.
Enfin, notre RFC se termine par une description, en section 5, d'un
modèle de référence des réseaux autonomes, reprenant les points vus précédemment.
