J. Chroboczek (IRIF, University of Paris-Diderot)January20212021-01-12
Comme tout bon protocole, le protocole de
routageBabel,
normalisé dans le ne fait
pas de miracles et ne marche pas dans tous les cas. Il est donc
utile de savoir quels sont les cas où Babel est efficace et utile. Ce
RFC s'applique à
identifier et documenter les créneaux pour Babel.
C'est qu'il en existe beaucoup de protocoles de routage internes
à un AS. Le
RFC cite
OSPF () et IS-IS (), qui
ont la faveur des grands réseaux gérés par des professionnels, mais
je trouve que Babel se situe plutôt du côté
de protocoles prévus pour des réseaux moins organisés, comme
Batman ou RPL (). Je vous laisse lire le pour voir comment fonctionne Babel. Disons
juste que c'est un protocole à vecteur de
distances (comme RIP - - mais
sans ses inconvénients) et qui considère la faisabilité de chaque
route potentielle avant de l'ajouter, supprimant ainsi le risque de
boucles. En refusant des routes qui pourraient peut-être créer une
boucle, le risque est la famine, l'absence de route pour une
destination, risque dont Babel se protège avec un mécanisme de
numéro de séquence dans les annonces.
La section 2 de notre RFC explicite les caractéristiques de
Babel, les bonnes et les mauvaises. D'abord, la
simplicité. Babel est conceptuellement simple,
ce qui facilite les analyses du protocole, et aussi sa mise en
œuvre. Comme le note le RFC, Babel peut être expliqué en un
micro-siècle. Et question programmation, le RFC cite une mise en
œuvre de Babel réalisée en deux nuits (le RFC ne dit pas ce que le
ou la programmeur·e faisait de jour…)
Ensuite, la résistance. Babel ne dépend que
de quelques propriétés simples du réseau et peut donc fonctionner
dans un large éventail de situations. Babel demande juste que les
métriques soient strictement monotones croissantes (emprunter le chemin A
puis le B, doit forcément coûter strictement plus cher que de juste
prendre le chemin A, autrement des boucles pourraient se former) et
distributives à gauche
(cf. « Metarouting »
de Griffin et Sobrinho). En revanche, Babel n'exige pas un transport
fiable (les paquets ont le droit de se perdre, ou de doubler un
autre paquet) et n'exige pas que la communication soit transitive
(dans les liens radio, il peut arriver que A puisse joindre B et B
puisse parler à C, sans que pour autant A puisse communiquer
directement avec C). Des protocoles comme OSPF () ou IS-IS sont bien plus
exigeants de ce point de vue.
Babel est extensible : comme détaillé dans
l'annexe C du , le protocole
Babel peut être étendu. Cela a été fait, par exemple, pour permettre
du routage en fonction de la source (draft-ietf-babel-source-specific)
ou bien du routage en fonction du RTT (draft-ietf-babel-rtt-extension). Il y a aussi des
extensions qui n'ont pas (encore ?) été déployées comme du routage
en fonction des fréquences radio (draft-chroboczek-babel-diversity-routing)
ou en fonction du ToS (draft-chouasne-babel-tos-specific).
Mais Babel a aussi des défauts, notamment :
Babel envoie périodiquement des messages, même quand il n'y
a eu aucun changement. Cela permet de ne pas dépendre d'un
transport fiable des paquets mais c'est du gaspillage lorsque le
réseau est stable. Un grand réseau très stable et bien géré a donc
plutôt intérêt à utiliser des protocoles comme OSPF, pour diminuer le
trafic dû au routage. À l'autre extrémité, certains réseaux de
machines contraintes (par exemple tournant uniquement sur
batterie) n'auront pas intérêt à utiliser
un protocole comme Babel, qui consomme de l'énergie même quand le
réseau n'a pas changé.Avec Babel, chaque routeur connait toute la table de
routage. Si des routeurs sont limités en mémoire, cela peut être
un problème, et des protocoles comme AODV (),
RPL () ou
LOADng sont
peut-être plus adaptés.Babel peut être lent à récupérer lorsqu'il fait de
l'agrégation de préfixes, et qu'une route plus spécifique est retirée.
Babel a connu plusieurs déploiements dans le monde réel (section
3). Certains de ces déploiements étaient dans des réseaux mixtes,
mêlant des parties filaires, routant sur le préfixe, et des parties
radio, avec du routage mesh sur les adresses IP. Babel a aussi
été déployé dans des
overlays, en utilisant
l'extension tenant compte du RTT, citée plus haut. Il a aussi été utilisé dans
des réseaux purement mesh. Voir à ce sujet les articles
« An
experimental comparison of routing protocols in multi hop ad hoc
networks » et
« Real-world
performance of current proactive multi-hop mesh
protocols ». Ces
réseaux utilisent traditionnellement plutôt des protocoles comme
OLSR (). Enfin, Babel a été
déployé dans des petits réseaux non gérés (pas
d'administrateur système).
Et la sécurité, pour finir (section 5). Comme tous les protocoles
à vecteur de distance, Babel reçoit l'information de ses voisins. Il
faut donc leur faire confiance, un voisin menteur peut annoncer ce
qu'il veut. En prime, si le réseau sous-jacent n'est pas lui-même
sécurisé (par exemple si c'est du WiFi sans WPA), il n'y a même pas besoin d'être
routeur voisin, toute machine peut tripoter les paquets.
Pour empêcher cela, il y a deux solutions cryptographiques, dans les (la solution la plus simple) et (plus complexe mais plus sûre et qui
fournit en prime de la confidentialité). La
solution avec le MAC, normalisée dans le , est celle recommandée car elle
convient mieux au caractère de la plupart des réseaux utilisant
Babel. (Le RFC n'en parle apparamment pas, mais notez
qu'authentifier le voisin ne résout pas complètement le problème. On
peut être authentifié et mentir.)
Enfin, si on n'utilise pas de solution de confidentialité, un
observateur peut déduire des messages Babel la position d'un routeur
WiFi qui se déplacerait, ce qui peut être considéré comme un
problème.
Sinon, pour creuser cette question de l'applicabilité de Babel,
vous pouvez lire le texte, très vivant, « Babel
does not care ».