Résumé

  • Le projet ROLL en cours propose 0x0B pour Response Spreading et 0x0C pour DIO Option Request. Dans le registre IANA des options RPL, ces deux valeurs désignent déjà RREQ et RREP, conformément à la RFC 9854. La version 02 demandait les mêmes codes ; la version 03 perpétue le conflit.
  • Le drapeau N du projet ferait répondre une fois les routeurs sollicités par DIS multicast sans remettre à zéro leur temporisateur Trickle. La section sécurité précise que des sollicitations répétées, des contraintes malveillantes et les anciens routeurs peuvent encore dépenser énergie, capacité radio et calcul.

Le registre n'est pas une liste de souhaits

Une option de message RPL commence par un type numérique. Ce type indique au récepteur comment lire les octets suivants. RFC 9854 a fait inscrire 0x0B pour RREQ et 0x0C pour RREP ; le tableau IANA les publie toujours sous ces noms. La section 7.2 du projet ROLL attribue les mêmes valeurs à deux options différentes. Les auteurs précisent que l'IANA doit encore confirmer les numéros. C'est précisément ce que le registre interdit de présumer : proposer une valeur ne la rend pas disponible.

Si un code porte deux sens dans un même espace, les équipements n'ont pas de règle commune pour interpréter ce qui suit. Le document de travail doit choisir d'autres valeurs libres ou décrire une autre solution d'encodage avant qu'une mise en œuvre puisse traiter ces nouvelles options sans ambiguïté. Le texte précédent contenait déjà cette demande ; il serait trompeur de présenter la révision du 28 octobre comme la naissance du problème. Aucun paquet réellement mal interprété n'est établi par ces sources.

Le problème que la modification cherche à résoudre, lui, est net. Selon RFC 6550, un nœud RPL peut envoyer un DIS en multicast pour découvrir les routeurs d'un graphe qu'il ne connaît pas encore. Les voisins concernés traitent cette sollicitation comme une incohérence et redémarrent leur temporisateur Trickle. Ils diffusent ensuite des DIO plus fréquemment pendant un certain temps. Pour le nœud qui cherche à rejoindre le réseau, l'information arrive. Pour les voisins, la facture s'étale en émissions supplémentaires, réception et risque d'encombrement.

Le nouveau drapeau N change le mécanisme de réponse : pas de remise à zéro de Trickle, mais un DIO envoyé explicitement en réponse. Le drapeau T peut imposer un DIO unicast, qui évite de réveiller les récepteurs n'ayant rien demandé. L'option Response Spreading étale les réponses de plusieurs voisins dans un intervalle choisi, afin d'éviter qu'elles partent toutes au même instant. Le drapeau R et l'option DIO Option Request limitent les éléments présents dans le DIO.

Ces détails ont une logique commune : celui qui pose une question devrait préciser la réponse dont il a besoin plutôt que de déclencher un bavardage prolongé dans tout le voisinage.

La facture revient si l'on sonne dix fois

La sécurité du dispositif repose sur autre chose qu'un drapeau. La section 8 explique qu'un attaquant capable d'injecter ou de modifier des DIS peut obtenir des réponses supplémentaires, manipuler l'étalement des réponses ou imposer des calculs de métriques. Des contraintes choisies pour écarter les bons voisins peuvent aussi retarder la découverte. N réduit le trafic Trickle déclenché par une sollicitation sur des routeurs compatibles ; il n'empêche pas un adversaire de répéter sa demande. Les routeurs anciens peuvent, eux, continuer à redémarrer Trickle comme le prévoit RFC 6550, même lorsqu'un demandeur récent réclame une réponse ponctuelle.

Le projet ne crée pas de nouvelle authentification. Il recommande d'employer les protections RPL existantes, de contrôler les longueurs et types d'options, de borner les ressources et d'envisager une limitation des requêtes répétées. Cette liste place la charge de la décision là où elle se trouve : chez les opérateurs et les implémenteurs qui doivent faire cohabiter générations de routeurs et demandes potentiellement abusives. Une demande émise par un nœud ne lui confère pas un droit illimité sur les piles des autres.

La fiche Datatracker présente la version 03 comme Internet-Draft actif du groupe de travail ROLL. Il reste à voir une version avec des codes disponibles et un relevé comparant le coût radio de voisins récents et anciens sous sollicitations répétées. Voilà les deux faits qui permettraient de juger l'économie promise.

Sources