Résumé

  • La révision 04 du projet SAND exige une protection BPSec, mais laisse au nœud annonceur le choix des types, instances et filtres appliqués selon le réseau sous-jacent, le point de terminaison et la destination BP ; elle prévoit explicitement des vues éventuellement disjointes.
  • Une donnée reçue et authentifiée n’est pas automatiquement utilisable : le découvreur l’autorise ou l’écarte localement, tandis qu’une annonce de route demande encore une décision distincte avant installation.
  • Une comparaison sérieuse commence par un reçu de projection reliant Source, Security Source, Previous Node, destination, interface, version de politique, Reference Time, validité, remplacement et décision du récepteur.

Le mot « découverte » suggère une opération neutre : un objet existe, un protocole le révèle, un inventaire le conserve. SAND décrit une réalité plus politique. Un nœud révèle une partie de ce qu’il sait dans un contexte précis. Le destinataire décide ensuite quelle partie il est autorisé à utiliser. La carte finale résulte donc de deux pouvoirs locaux, pas d’une copie passive du monde.

Le projet Bundle Protocol Secure Advertisement and Neighborhood Discovery s’inscrit dans BPv7 et les réseaux tolérants aux délais. Il organise des messages portant sur les sollicitations, les identifiants et certificats, les réseaux sous-jacents, les couches de convergence, les ressources, la topologie locale, la volonté de router et les endpoints. Cette richesse peut alimenter une exploitation automatisée. Elle rend aussi indispensable une discipline de portée.

La question n’est pas simplement : « La signature est-elle valide ? » Elle est : « Quelle déclaration cette signature protège-elle, pour quel destinataire, sur quelle interface, à quel instant, et quelle autorité a décidé d’en faire quoi ? »

L’auteur, le dernier relais et la clé ne sont pas un seul champ

Un SAND Bundle possède une Source EID et une destination, soit le groupe SAND, soit un autre Singleton EID SAND. Pour une diffusion destinée aux voisins immédiats, le Hop Limit vaut un. Cette portée ne supprime pourtant pas la différence entre origine et relais.

Lorsqu’un bundle a été relayé, SAND exige une identification positive du previous hop. La priorité va à l’identité authentifiée de la convergence layer lorsqu’elle existe, puis à un bloc Previous Node authentifié, puis, au premier saut, au Source Node ID authentifié du bloc primaire. Le dernier émetteur peut donc ne pas être la source du contenu.

Tous les bundles SAND doivent contenir un Block Integrity Block protégeant le payload. La Security Source de ce BIB doit désigner le même nœud que la Source EID du bundle, tout en pouvant employer une EID différente selon la politique d’identité. Un bloc Previous Node reçoit sa propre protection, associée au nœud précédent.

Cette architecture conserve trois questions : qui a créé l’annonce, qui l’a remise à ce saut et quelle identité cryptographique protège chaque bloc. Les normaliser immédiatement en un unique identifiant de machine détruit une partie de la chaîne de responsabilité. La politique qui conclut que deux EID désignent un même nœud doit elle aussi rester vérifiable.

BPSec répond ainsi avec force à la provenance et à l’intégrité de la déclaration protégée. Il ne prouve pas que la déclaration est exhaustive, identique pour tous les destinataires ou autorisée pour le routage.

Le demandeur ne possède pas le droit de tout savoir

Une Data Solicitation exprime un besoin. Elle n’impose pas la divulgation. La révision 04 dit que la sollicitation ne doit pas supplanter la politique locale de l’annonceur. Le nœud choisit seul les types de message diffusés, puis les instances retenues dans chaque type.

Ce choix répond parfois à l’efficacité : ne pas répéter un certificat stable, exclure un point de terminaison désactivé, omettre un paramètre sans intérêt pour ce support. Il peut aussi protéger une frontière : une annonce vers un groupe ne livre que le minimum permettant un premier contact, tandis qu’une destination singleton bénéficiant d’une meilleure sécurité reçoit davantage d’informations.

Le filtrage contextuel peut dépendre de l’ULN, du point de terminaison, de la source ou de la destination BP. Une hiérarchie PKIX privée peut n’être montrée que sur le réseau qui lui fait confiance. Une instance de convergence IPv6 peut apparaître sur une terminaison IPv6 et disparaître ailleurs. Plusieurs filtres peuvent se combiner.

Le projet emploie alors une formule remarquable : cette méthode peut produire une sorte de « split brain », où des voisins différents observent des ensembles différents, voire sans aucun recouvrement, associés au même annonceur. Il ne s’agit pas nécessairement d’un mensonge ni d’une perte. C’est l’effet prévisible d’une divulgation contextualisée.

Cette asymétrie répond aussi à une contrainte de confidentialité. Dans le scénario initial de groupe à configuration nulle, le payload peut être observable faute de chiffrement additionnel. Le Hop Limit d’un saut n’empêche pas un middlebox d’observer le bundle. Masquer des noms DNS, des adresses, des voisins ou des certificats sur certaines terminaisons peut donc être la politique correcte.

Un inventaire central commet une erreur s’il transforme « non divulgué ici » en « inexistant partout ».

Le récepteur exerce une seconde souveraineté

Même après réception conforme, le nœud découvreur n’est pas obligé d’utiliser le message. Les structures sont obligatoires à comprendre pour une implémentation conforme, mais leur emploi reste local.

L’autorisation peut dépendre du type de message, de la source, de la destination, des paramètres de convergence au moment de la réception ou d’informations apprises auparavant. Le récepteur peut ensuite écarter des éléments sans utilité locale. Un système limité à IP peut ignorer des paramètres non IP. Une adresse actuellement sans route peut rester hors de la représentation active.

Cette élimination n’est pas un verdict universel. Une route absente aujourd’hui peut apparaître demain. Une donnée non interprétable par cette version du logiciel peut devenir utile après une mise à niveau. Il faut donc distinguer trois absences : l’annonceur n’a pas divulgué l’élément, le récepteur ne l’a pas autorisé, ou sa représentation locale l’a écarté.

La révision 04 révèle aussi une dépendance d’implémentation. Une autorisation contextuelle exige de relier le message reçu à son bundle d’origine et à l’instance locale de convergence par laquelle il est arrivé. Certaines interfaces entre le BP Agent et l’application n’exposent pas ce contexte. Une politique rédigée dans un document ne peut fonctionner si le code qui tranche ne reçoit pas les éléments nécessaires.

La carte affichée est donc déjà une projection d’une projection. La première vient du filtre de l’émetteur. La seconde vient de l’autorisation et du culling du récepteur.

L’ordre temporel prime sur le simple fait de recevoir

Les messages SAND décrivent l’ensemble complet d’un type pour le nœud annonceur. Ils ne reposent pas sur une série d’incréments à appliquer dans l’ordre. Cela rend leur traitement idempotent et tolérant aux doublons, caractéristique utile dans BPv7.

Après traitement, le récepteur mémorise le Reference Time par source et type de message, ou utilise le Creation Timestamp à défaut. Avant de traiter le prochain message, il vérifie cette valeur. Un message d’heure identique ou antérieure doit être ignoré. Le classement combine DTN Time et Sequence Number. Ignorer un message remplacé n’est pas un échec.

Deux bundles peuvent donc posséder des signatures valides tout en n’ayant pas le même droit de modifier l’état courant. Une répétition malveillante peut consommer des ressources, mais ne devrait pas restaurer une vue plus ancienne si la règle est appliquée. À l’inverse, un émetteur qui ne parle que lors d’un changement dépend de la livraison du message de remplacement ; une perte peut laisser survivre une vieille projection.

Validity Duration, Repetition Interval, émission périodique et émission sur changement définissent ensemble la signification du silence. La date d’arrivée dans un collecteur ne remplace pas le temps de référence du message.

Une relation SYMMETRIC ne certifie pas un service

Local Topology Advertisement décrit les voisins d’un saut. HEARD signifie qu’un message du pair a été reçu sans que ce nœud apparaisse encore dans la topologie publiée par le pair. SYMMETRIC indique que le pair annonce ce nœud, donc qu’au moins un message a été reçu dans chaque direction. LOST signifie qu’aucun message n’a été reçu pendant un délai défini par l’implémentation.

Ces états ne prouvent ni capacité durable, ni chemin applicatif, ni transaction achevée. Les métriques de deux voisins mutuels ne sont pas synchronisées. Même lorsque les mêmes éléments sont annoncés, la spécification ne promet pas l’égalité des valeurs. Leur réconciliation relève de l’implémentation.

Router Advertisement garde la même modestie. Un nœud indique une willingness de zéro à six et peut annoncer des motifs de réseaux attachés, y compris un motif de passerelle *:**. Le texte précise qu’un tel signal ne devrait être visible que dans un réseau stub approprié. Surtout, enregistrer l’annonce, autoriser son utilisation pour le routage et installer effectivement la route sont trois décisions distinctes.

Sans autorisation correcte, les menaces de route leak et de hijacking demeurent. Le projet observe qu’il n’existe pas pour le routage BP un équivalent direct de RPKI. Une annonce protégée reste donc une entrée attribuable ; elle n’est pas un mandat de routage.

Construire un reçu de projection

Le contrôle manquant peut prendre la forme d’un reçu de projection d’annonce. Cette proposition relève de l’exploitation et non d’une obligation normative de la révision 04.

Le reçu conserve le hash du bundle protégé, son identité, la Source EID, la Security Source, le Previous Node, la destination, le Hop Limit, le Creation Timestamp et l’heure de réception. Il précise la méthode d’identité effectivement utilisée. Il associe ensuite la déclaration à l’ULN, au point de terminaison et à l’instance de convergence de l’envoi ou de la réception.

Pour chaque type de message, il enregistre les instances présentes, le Reference Time, la Validity Duration, le Repetition Interval et le résultat de supersession. Il épingle, si possible, la version de la politique de filtrage de l’annonceur. Côté récepteur, il conserve l’autorisation, le culling et leurs motifs, puis un hash de la projection réellement stockée.

Le reçu s’arrête avant d’usurper les décisions suivantes. L’installation d’une route a besoin de sa propre autorité. L’observation du forwarding et le résultat applicatif ont besoin de preuves ultérieures. Séparer ces couches ne crée pas de bureaucratie gratuite : cela empêche le booléen « authentifié » de signifier à la fois complet, autorisé, routé et livré.

Avec deux reçus, la divergence devient classable : portée volontaire, différence de version de politique, ancienneté, message remplacé, culling local, fonction non prise en charge, perte, erreur de configuration ou anomalie encore inexpliquée. Sans reçu, l’enquête ne dispose que de deux copies d’écran.

Un projet actif, pas une preuve de déploiement

Datatracker présente la révision 04 comme un Internet-Draft actif du groupe DTN, publié le 8 septembre 2026 et expirant le 12 mars 2027. Son en-tête mentionne Standards Track, tandis que le champ Datatracker « intended RFC status » était vide lors du gel. Ce n’est ni un RFC ni une allocation finale.

La section Implementation Status cite un prototype d’exemple. Elle précise également que les informations ont été fournies par des contributeurs, n’ont pas été vérifiées, ne constituent pas un catalogue et n’impliquent aucun soutien de l’IETF. Aucun taux d’adoption, résultat d’interopérabilité, comportement produit, incident ou route leak réel n’est revendiqué ici.

RFC 9171 fournit BPv7, RFC 9172 BPSec, RFC 8949 et RFC 8610 CBOR/CDDL. RFC 6130 donne un parallèle pour la découverte de voisinage. RFC 4593, RFC 7908 et RFC 6480 fixent le contexte des menaces de routage, des leaks et de RPKI. Aucun de ces textes ne transforme une projection SAND locale en vérité globale.

La bonne conclusion reste bornée : l’authentification attribue une déclaration située. La complétude, l’autorité de routage et l’issue du service exigent d’autres reçus.