Résumé

  • La chaîne RPKI-routeur sépare l'autorité de l'action. Les détenteurs de ressources et les autorités de certification publient des objets signés; les logiciels de validation les vérifient et exportent des charges utiles validées; les routeurs classifient les routes; les opérateurs décident ce que Valid, Invalid et NotFound signifient dans la politique d'importation, de meilleur chemin et d'exportation locale.
  • Le RFC 8481 a rendu la frontière explicite en 2018: les implémentations doivent définir l'état de validation, mais aucune politique ne doit être appliquée sans configuration spécifique de l'opérateur. L'opérateur, et non le registre ou le validateur, prend la décision finale de traitement.
  • Le contrôle local ne rend pas les acteurs en amont sans importance. Un certificat, une révocation, une ROA ou un état de dépôt erroné peut altérer chaque classification en aval qui le suit correctement. La responsabilité doit donc être divisée par l'acte contrôlé, plutôt que d'être attribuée entièrement à un registre ou à un réseau transportant la route.
  • « Invalid » est un résultat cryptographique et syntaxique par rapport aux données validées disponibles à un moment donné. C'est une preuve solide pour la politique de routage, mais cela n'identifie pas si la cause sous-jacente est un détournement, une erreur du détenteur, un retard de transfert, un maxLength incorrect, une action de certificat défavorable ou des données de validation obsolètes.
  • La politique de routeur n'est pas un simple interrupteur binaire. Les réseaux peuvent rejeter les routes Invalid, les conserver mais les rendre inéligibles à la sélection du meilleur chemin, réduire leur préférence, limiter leur traitement par classe de pair, alerter en premier, ou maintenir des exceptions locales étroites. Chaque choix a des effets différents sur la sécurité, l'accessibilité et la récupération.
  • La chaîne opérationnelle a un timing et un état. Les sessions du protocole RPKI-Router transportent des annonces et des retraits des caches, utilisent des identifiants de série et de session, et spécifient un comportement d'actualisation, de nouvelle tentative et d'expiration. Une correction au registre ne devient une décision de réacheminement réparée qu'après la convergence de la publication, de la validation, du transfert du cache et de la réévaluation du routeur.
  • La gouvernance devrait exiger des reçus de décision à chaque frontière: l'objet signé et la raison du changement, la version du validateur et les entrées de confiance, le numéro de série et l'âge du cache, la version de la politique du routeur, la classe de pair affectée, la conséquence de route observée, l'autorité d'exception et le temps de récupération. Un label sans cette preuve est trop léger pour un appel ou une responsabilité.
  • Une Société des ressources numériques peut comparer ces frontières, tester les chemins de correction et représenter les petits opérateurs en tant qu'organisation d'adhésion et de défense, sans devenir un contrôleur de routage mondial, un opérateur RPKI ou un registre. Son rôle utile est de rendre l'autorité et le remède lisibles tout en préservant le droit et le devoir de l'opérateur de décider de la politique de routage locale.

La décision finale est locale par conception

La phrase la plus conséquente de la validation d'origine moderne ne se trouve pas dans un contrat de registre ou un guide de commandes de routeur. Elle apparaît dans le RFC 8481, publié en septembre 2018: une fois que les routes ont été évaluées et que leur état de validation est défini, l'opérateur doit avoir un contrôle complet sur la politique appliquée à partir de cet état. Sans configuration spécifique de l'opérateur, la politique ne doit pas être appliquée. L'instruction de la norme est « définir l'état, ne pas agir ».

Cette distinction répond à la question étroite de savoir qui décide du traitement final d'une route Invalid. C'est l'opérateur réseau. Un RIR peut exploiter un ancrage de confiance, délivrer des certificats, héberger un service de certification et publier des objets. Un détenteur de ressources peut autoriser un AS d'origine dans une ROA. Un validateur peut récupérer les dépôts, authentifier un chemin de certificat et produire des charges utiles ROA validées. Un routeur peut comparer une annonce BGP avec ces charges utiles et attacher un état.

Aucune de ces étapes, à elle seule, ne décide si un réseau particulier accepte la route d'un client, la préfère à un pair, l'exporte vers un transit ou l'installe dans une table de transfert.

La réponse est simple seulement si « décide » signifie la dernière action configurée. Cela devient plus difficile lorsque décider est confondu avec causer. Une erreur de registre peut amener un validateur correct à supprimer une autorisation. Un cache correct peut amener un routeur à reclasser une route de longue date. Un défaut de fournisseur peut rendre une politique plus agressive que ce que son opérateur comprenait. Le rejet d'un fournisseur de transit peut rendre un détenteur inaccessible même pendant que le réseau du détenteur continue d'accepter la route.

Plusieurs institutions peuvent être causalement importantes, mais une seule administration réseau contrôle chaque décision de routage locale.

Cette distribution est une caractéristique constitutionnelle du routage interdomaine. Les systèmes autonomes sont autonomes en partie parce qu'ils choisissent à qui se connecter et quelles routes utiliser. Transformer un objet signé d'un registre en une instruction de télécommande universelle concentrerait le pouvoir de routage dans la hiérarchie de certification et effacerait les différences de risque, d'obligation client et de connaissance locale. Inversement, prétendre que le registre ne fait que publier des informations inoffensives sous-estime à quel point ses objets authentifiés peuvent façonner une politique automatisée.

Une bonne gouvernance doit tenir les deux propositions ensemble. Les autorités de certification sont responsables des déclarations et des changements d'état qu'elles contrôlent. Les opérateurs sont responsables de la politique de routage qu'ils choisissent et de la résilience avec laquelle ils l'appliquent. La couche manquante n'est pas un nouveau décideur central entre eux. C'est une allocation visible des devoirs, des preuves et des recours à travers la frontière.

Quatre verbes empêchent qu'une seule institution hérite de tous les devoirs

Le débat public comprime souvent la validation d'origine en un seul verbe: « le RPKI bloque les détournements ». L'expression est une défense utile et une mauvaise analyse institutionnelle. Quatre verbes différents sont impliqués: autoriser, valider, classifier et agir. Chacun a un sujet, une base de preuve et un remède différents.

Un détenteur autorise une origine en émettant ou en demandant une ROA sous un chemin de certificat. Dans un service hébergé, un RIR peut contrôler davantage la clé et l'opération de publication; dans les arrangements délégués, le détenteur peut contrôler plus directement. La hiérarchie de certification établit si le signataire a l'autorité de ressource numérique pertinente. L'objet résultant indique qu'un AS est autorisé à annoncer un préfixe dans une limite de longueur spécifiée. Il n'annonce pas le préfixe en BGP et ne promet pas que la route est commercialement acceptable.

Un validateur valide. Il récupère les objets signés, vérifie les certificats, les listes de révocation, les manifests et les profils d'objet, et construit un ensemble actuel de charges utiles utilisables selon les normes et la configuration de confiance locale. C'est un jugement computationnel sur des données authentifiées. Différentes implémentations de validateur ou vues de dépôt peuvent temporairement diverger. Des filtres et des assertions locales peuvent également produire une vue qui diffère délibérément des données globales.

Un routeur classifie une route en comparant son origine et son préfixe avec les charges utiles validées. Les états familiers sont Valid, Invalid et NotFound. Valid signifie qu'au moins une autorisation pertinente correspond. Invalid signifie que des données d'autorisation couvrantes existent mais qu'aucune n'autorise l'origine et la combinaison de longueur de préfixe observées. NotFound signifie qu'aucune charge utile validée pertinente ne couvre la route. L'état décrit cette comparaison; ce n'est pas un compte rendu complet de l'historique ou de la légitimité de la route.

Enfin, un opérateur agit. Ses politiques peuvent rejeter, préférer, dé-préférer, mettre en quarantaine, étiqueter, journaliser ou excepter temporairement une route. Elles peuvent différer par client, pair, transit, route server, famille d'adresses, région ou service critique. Elles interagissent avec les filtres de préfixe, les données IRR, les limites de max-prefix, les communautés, la préférence commerciale et le transfert du préfixe le plus long.

Une route conservée à faible préférence peut toujours attirer du trafic lorsqu'elle est plus spécifique qu'un agrégat concurrent, un point que le RFC 7115 conseille aux opérateurs de ne pas négliger.

Le vocabulaire est important parce que la responsabilité devrait suivre le contrôle. Un signataire doit répondre d'une autorisation erronée. Un mainteneur de validateur doit répondre d'un défaut de validation reproductible dans le cadre de l'assurance offerte. Un opérateur de cache doit répondre d'un service de distribution non sécurisé ou obsolète qu'il a promis d'exploiter. Un réseau doit répondre de sa propre politique et de ses tests. Aucune couche ne devrait être autorisée à revendiquer le pouvoir de sa production tout en décrivant chaque conséquence comme le problème de quelqu'un d'autre.

Invalid est un état, pas un verdict sur le motif

Une classification Invalid est plus précise qu'une rumeur et plus étroite qu'une constatation judiciaire. En validation d'origine, cela signifie qu'au moins une charge utile validée couvre le préfixe de la route, mais qu'aucune charge utile ne couvre à la fois la longueur annoncée et ne nomme l'AS d'origine observé. Les mathématiques ne disent pas pourquoi il y a une divergence.

La divergence peut être une tentative de détournement d'origine. Elle peut aussi être un détenteur de ressources qui a changé de fournisseur de transit avant de changer sa ROA, une équipe opérationnelle qui a annoncé un préfixe plus spécifique au-delà de maxLength, un transfert dont l'état du certificat a changé avant que la coordination de routage ne soit terminée, ou une action de registre qui a retiré l'autorité de manière inattendue. Un validateur peut avoir une vue de dépôt plus récente que celle anticipée par le ticket de modification de l'opérateur.

Un routeur peut utiliser un cache tandis que l'outil de diagnostic d'un ingénieur en consulte un autre. Une assertion locale peut réparer ou créer une différence. Tous ces cas peuvent produire le même état de trois lettres sur une ligne de commande.

Cela ne rend pas Invalid une preuve faible. Le but de la validation d'origine est de transformer une autorisation authentifiée en un signal de routage utilisable, et le rejet des routes Invalid augmente matériellement le coût de la mésattribution accidentelle et malveillante. La classification est conçue pour soutenir l'action. Mais un contrôle de sécurité devient gouvernable seulement lorsqu'il peut distinguer le confinement immédiat de l'attribution finale.

Un opérateur peut raisonnablement rejeter une route Invalid d'abord et enquêter ensuite, surtout à une frontière de pair ou de transit où il n'y a pas d'exception client authentifiée. Cette action immédiate est un jugement de sécurité local. Si le détenteur affecté prétend qu'il y a une erreur, la question change. Les parties ont alors besoin du préfixe exact, de l'AS d'origine, des charges utiles couvrantes, de maxLength, de l'heure du validateur, du numéro de série du cache, de la politique du routeur et de la première transition observée.

Elles doivent savoir si une autorisation correspondante existait ailleurs, si un retrait a été publié et à quelle vitesse les différentes vues ont convergé.

Traiter chaque Invalid comme une preuve de conduite hostile refuse un droit de correction significatif. Traiter chaque Invalid comme un bruit de configuration inoffensif défait la protection. Le juste milieu procédural est: confiner selon la politique déclarée, préserver les preuves, fournir une voie d'escalade authentifiée, classifier la cause, corriger à la couche qui l'a introduite, et mesurer la restauration. Une telle procédure respecte à la fois la valeur du rejet automatisé et la possibilité que des données authentifiées puissent être erronées.

La question de gouvernance n'est donc pas de savoir si le label doit être fiable. C'est de savoir quelle affirmation le label soutient, pendant combien de temps, sous quelles entrées, et ce qui se passe lorsqu'une personne ayant un intérêt légitime le conteste.

L'autorité du registre est substantielle, mais elle s'arrête à la table de transfert

Les RIR occupent une position puissante parce que la hiérarchie de certificats RPKI suit l'administration des ressources numériques. Ils exploitent des ancres de confiance et des services régionaux, maintiennent des relations d'enregistrement et publient du matériel de certificat dont dépendent les validateurs. Dans les arrangements hébergés, ils peuvent générer et publier des ROA basées sur des instructions authentifiées du détenteur. Une révocation, un changement d'ensemble de ressources ou un échec de publication peut altérer les charges utiles que les validateurs produisent.

C'est une véritable autorité. Appeler le RPKI simplement une base de données optionnelle obscurcit l'effet de priorité cryptographique et de consommation automatisée. Une fois que de nombreux réseaux rejettent les routes Invalid, un changement erroné en amont peut être traduit en perte d'accessibilité à travers des réseaux indépendants. Le fait que chaque opérateur a librement configuré le rejet ne rend pas l'état de certificat erroné sans importance. Une autorité de pont ne peut pas désavouer son propre signal défectueux simplement parce que chaque conducteur a choisi d'obéir au feu.

Pourtant, un RIR n'exploite pas tous les routeurs BGP dans le monde. Il ne peut pas connaître chaque terme de peering bilatéral, dépendance de service d'urgence, route privée, fenêtre de maintenance client ou exception locale. Il ne peut pas forcer un réseau à rejeter une annonce Invalid, et ne devrait pas pouvoir le faire via une valeur par défaut non documentée. La règle de contrôle de l'opérateur du RFC 8481 empêche le logiciel de validation de convertir silencieusement l'état du registre en politique de routage.

La frontière devrait être exprimée dans des engagements de service. Les registres devraient garantir un contrôle authentifié, un traitement précis des instructions du détenteur, des opérations de clé protégées, une publication cohérente, des notifications, des corrections et des enregistrements préservés dans des limites définies. Ils devraient publier comment les modifications de certificat et de ROA sont autorisées, quelle voie d'urgence existe, quelles horodatations sont enregistrées, et comment les actions défavorables ou erronées peuvent être contestées.

Ils n'ont pas besoin de garantir que chaque réseau transporte chaque route corrigée ou de compenser toutes les pertes commerciales consécutives.

Les opérateurs, à leur tour, ne devraient pas blâmer un registre pour des choix que le registre n'a pas faits. Un réseau qui applique le rejet sans surveiller l'âge du cache, tester la réévaluation ou fournir une voie d'escalade client possède ces décisions de conception. Un fournisseur qui ignore une charge utile corrigée parce que son routeur a supprimé le chemin et ne l'a jamais récupéré possède un échec différent. Un réseau qui continue d'accepter une mésattribution connue pour des raisons commerciales ne peut pas décrire cette acceptation comme forcée par le RIR.

Des frontières visibles rendent la responsabilité plus forte plutôt que plus faible. Elles identifient l'institution capable de réparer. Le registre peut corriger l'état d'autorisation. L'opérateur du validateur peut corriger la récupération ou la validation. Le vendeur de routeur peut corriger l'implémentation. Le réseau peut changer la politique et restaurer la route. Une affirmation vague de responsabilité partagée signifie souvent que personne n'a un chronomètre en marche.

Les validateurs sont des interprètes indépendants, pas des cours d'appel

Le logiciel reproposé se place entre la publication signée et la consommation du routeur. Il recueille des objets de dépôts distribués, les authentifie par rapport aux ancres de confiance configurées, applique les règles de validation et produit un ensemble de charges utiles. Le RFC 8897 consolide de nombreuses exigences pour ce rôle, tandis que des implémentations indépendantes offrent une diversité utile dans l'analyse, la récupération, la gestion du cache et les pratiques de publication.

La discrétion du validateur est limitée. Il peut rejeter un objet malformé, considérer une chaîne obsolète ou révoquée comme inutilisable, choisir un comportement de transport de dépôt dans les normes, et exposer des diagnostics. Il ne peut pas déclarer une ROA correctement authentifiée injuste et substituer une autorisation globale différente simplement parce qu'un opérateur conteste le registre. S'il le faisait, les mainteneurs de logiciel deviendraient des organes d'appel non nommés sur l'autorité des ressources numériques.

Il existe néanmoins une autonomie locale. Le RFC 8416 définit SLURM, permettant à un opérateur de filtrer les charges utiles validées ou d'ajouter des assertions locales. Cela peut protéger les routes pendant une action défavorable ou permettre un usage privé que le RPKI global ne peut pas représenter. L'adjectif important est « local ». Une exception change la vue utilisée par cet opérateur et les clients auxquels il fournit délibérément la vue modifiée. Elle ne réécrit pas l'état signé pour les autres réseaux.

L'opération de validateur contient donc des choix de gouvernance qui devraient être déclarés. Quels localisateurs d'ancrage de confiance sont acceptés? Des filtres ou assertions locaux sont-ils chargés? Quels transports de dépôt sont activés? Comment les données obsolètes sont-elles traitées? Quelle version du validateur et quelles bibliothèques cryptographiques fonctionnent? Le routeur reçoit-il une vue de cache ou en sélectionne-t-il plusieurs? Qui peut approuver une exception, à quel point peut-elle être étroite, quand expire-t-elle et quelles preuves la clôturent?

Exécuter plusieurs validateurs est précieux mais ne répond pas à ces questions par lui-même. Deux instances peuvent partager un chemin de dépôt, une configuration de confiance ou un canal de paquet. Lorsque leurs sorties diffèrent, le vote majoritaire peut préserver un état obsolète aussi facilement qu'il peut identifier un défaut. Une comparaison utile explique la différence au niveau de l'objet et de l'entrée: quels octets ont été récupérés, quel chemin de certificat a été accepté, quel numéro de série a été exporté et quelle charge utile a été ajoutée ou retirée.

C'est aussi pourquoi les validateurs ne devraient pas absorber la politique de routage. Ils devraient fournir un état de haute qualité, une provenance, un âge et des informations d'erreur. La couche de politique réseau et routeur devrait décider du traitement opérationnel. Combiner validation et rejet derrière un service géré opaque peut être pratique, mais cela cache le transfert le plus important: le moment où une déclaration authentifiée devient une décision de connectivité.

Le protocole RPKI-Router transporte l'état, pas le consentement institutionnel

Le RFC 8210 décrit le pont pratique d'un cache validé aux routeurs. Le routeur établit une relation avec un ou plusieurs caches, choisit selon la préférence configurée et demande un ensemble complet ou incrémental de données. Les identifiants de session distinguent les instances de cache; les numéros de série identifient les versions logiques au sein d'une session. Les annonces et retraits de préfixe ajoutent ou suppriment des enregistrements validés exacts. Un message End of Data complète une mise à jour cohérente et transporte des paramètres de temporisation.

Ces détails sont opérationnellement importants parce que la politique est appliquée à un état qui change dans le temps. Un cache peut notifier à un routeur que de nouvelles données sont disponibles, mais la notification est un indice; le routeur interroge toujours. Si l'historique incrémental est indisponible, le routeur peut se réinitialiser et demander un ensemble complet ou passer à un autre cache. Si l'identité de session change de manière inattendue, les enregistrements obsolètes peuvent devoir être vidés.

Un retrait dans le protocole cache-routeur supprime un droit précédemment annoncé avec le même préfixe, la même longueur maximale et le même ASN.

Le modèle de temporisation crée une fenêtre de continuité limitée. Un intervalle d'actualisation indique quand le routeur devrait interroger à nouveau. Un intervalle de nouvelle tentative régit les tentatives après un échec. Un intervalle d'expiration limite la durée pendant laquelle les données actuelles du cache peuvent continuer à être utilisées sans renouvellement réussi. Les valeurs par défaut recommandées par le RFC 8210 sont des paramètres d'ingénierie, pas des promesses de service universelles, et les déploiements peuvent configurer des valeurs dans des plages spécifiées.

Ce qui importe institutionnellement, c'est qu'une autorisation obsolète n'a pas une durée de vie indéfinie simplement parce qu'une connexion de cache a échoué.

En même temps, l'expiration peut changer le risque d'accessibilité. Lorsque les données validées disparaissent, les routes peuvent évoluer vers un traitement NotFound ou un autre état spécifique à l'implémentation, selon l'architecture et la politique. Une conception qui rejette uniquement les routes Invalid peut échouer en ouvert après expiration. Une conception qui traite la perte de validation comme un motif de rejet large peut échouer en fermé et déconnecter des réseaux valides. Le comportement de transport standard ne peut pas choisir quel risque de continuité l'opérateur devrait préférer.

L'existence du protocole peut tenter les institutions de surinterpréter le message. Une PDU Prefix n'est pas une directive d'un RIR à un routeur. Ce sont des données émises par un cache approuvé par l'opérateur du routeur, dérivées de la vue validée du cache. Son numéro de série prouve l'ordre au sein de cette session de cache, pas un accord entre registres ou une permission sous un contrat de peering. L'utilisation que le routeur en fait reste un acte local configuré.

Un déploiement gouvernable enregistre le transfert. Il peut montrer quelle session de cache et quel numéro de série ont fourni la charge utile utilisée pour une décision contestée, quand le routeur l'a acceptée, quand un retrait ultérieur est arrivé et quand les chemins affectés ont été réévalués. Sans cet enregistrement, l'étape la plus décisive sur le plan opérationnel laisse moins de preuves que la cérémonie de certificat en amont.

Les routeurs offrent plusieurs traitements, chacun avec un remède différent

La documentation des routeurs des vendeurs et open source confirme que la validation d'origine n'impose pas une action universelle. Les exemples Cisco montrent des politiques qui attribuent une préférence locale différente aux routes Valid, NotFound et Invalid, et des alternatives qui maintiennent les chemins Invalid tout en les empêchant de devenir les meilleurs. Les conseils Juniper séparent la politique qui marque l'état de validation du terme ultérieur qui rejette une route Invalid. FRRouting expose des correspondances de route-map pour les mêmes états et peut réduire la préférence au lieu de supprimer le chemin.

Le premier traitement est le rejet dur à l'importation. Il empêche la route d'entrer dans l'ensemble de décision BGP utilisable à cette frontière. Cela offre une protection claire mais peut compliquer la récupération si l'implémentation n'a pas conservé le chemin rejeté. Lorsqu'une ROA corrigée arrive, le routeur peut avoir besoin de routes stockées avant politique, de reconfiguration logicielle ou d'un rafraîchissement de route du voisin.

Le RFC 9324 traite du préjudice causé lorsque de nouvelles données RPKI déclenchent des rafraîchissements fastidieux et recommande de conserver les chemins affectés par la politique RPKI pour qu'ils puissent être réévalués localement.

Le deuxième traitement conserve le chemin mais le rend inéligible pour la sélection du meilleur chemin. Il peut récupérer rapidement lorsque la validation change parce que la route reste disponible pour la réévaluation. Il consomme de la mémoire et nécessite l'assurance que le chemin ne peut pas fuir accidentellement dans le transfert ou l'exportation. Les preuves devraient distinguer « conservé pour récupération » de « accepté comme utilisable ».

Le troisième traitement réduit la préférence. Cela peut soutenir un déploiement progressif ou une transition spécifique au client, mais ce n'est pas équivalent à la sécurité. Si la route Invalid est le seul chemin, elle peut encore gagner. Si elle est plus spécifique qu'un agrégat Valid, le transfert du préfixe le plus long peut attirer du trafic indépendamment d'une préférence BGP inférieure. L'exception doit être conçue autour des conséquences réelles de transfert, pas seulement des cosmétiques de table de routage.

Le quatrième traitement est la surveillance et l'étiquetage avant application. Il donne aux opérateurs le temps d'identifier les erreurs client, de construire un service d'escalade et de tester l'équipement. Sa faiblesse est évidente: l'observation seule n'arrête pas un détournement. Un plan progressif a donc besoin de dates, de seuils et d'une approbation responsable plutôt que d'un pilote indéfini.

Enfin, un opérateur peut appliquer des exceptions locales étroites. Une exception peut être justifiée pour un détenteur vérifié pendant la correction, mais elle devrait spécifier le préfixe, l'origine, les sessions affectées, l'approbateur, les preuves, l'expiration et la révision. Un contournement permanent large crée silencieusement un second régime d'autorisation. Le remède contre un faux rejet et le contrôle contre une exception dangereuse sont la même chose: un état précis et limité dans le temps avec un enregistrement de décision préservé.

Le peering et le transit transforment un état en différentes obligations

Les réseaux ne reçoivent pas les routes dans un vide juridique. Une session client, une session de peering sans règlement, un flux de transit et une session de route server portent des attentes différentes. La validation d'origine entre dans ces relations comme une entrée parmi l'autorisation de préfixe, la portée d'exportation, l'ingénierie du trafic, la protection de max-prefix et la préférence commerciale.

Un fournisseur de transit promet généralement une accessibilité sous réserve de conditions d'utilisation acceptable et de sécurité de routage. S'il rejette la route Invalid d'un client, le client a besoin d'un avis clair et d'un moyen authentifié de démontrer une autorisation corrigée. Le fournisseur peut avoir de fortes raisons de rejeter, mais il devrait quand même identifier le préfixe, l'origine observée et les preuves de validation. « L'Internet dit Invalid » n'est pas une réponse de service adéquate car il n'y a pas un seul routeur Internet prenant la décision.

À une frontière de peering, un réseau peut n'avoir aucun devoir de transporter chaque route. Il peut adopter une politique stricte comme condition d'échange. Pourtant, la transparence compte toujours car une fausse classification peut affecter à la fois les pairs et leurs clients. Les coordinateurs de peering doivent savoir si le rejet provient du réseau local, d'un route server, d'un service de validation ou d'une communauté d'état propagée.

L'utilisation d'une communauté étendue de validation d'origine via iBGP ou des arrangements de route server peut distribuer l'état, mais le RFC 8481 met en garde contre une action automatique à moins que l'opérateur ne l'ait configurée.

Les route servers rendent la frontière particulièrement visible. Ils peuvent valider et filtrer pour le compte de nombreux membres, ou simplement attacher des informations et laisser chaque membre décider. Un service partagé peut améliorer la cohérence et réduire le coût de déploiement. Il peut aussi multiplier une erreur de configuration à travers un échange. Sa politique, ses droits d'exception, ses entrées de cache et ses avis de modification devraient donc être explicites dans les conditions de service et la documentation technique.

Les clients en aval compliquent l'attribution. Un petit réseau peut ne pas exploiter de validateur et ne recevoir que la politique effective de son amont. Sa route peut être rejetée loin du RIR qui a publié les données, sans chemin contractuel vers cet opérateur distant. C'est là que les institutions collectives peuvent aider: des avis normalisés et des preuves interopérables réduisent le besoin pour un petit détenteur de négocier séparément avec chaque réseau filtrant.

L'autonomie commerciale ne devrait pas devenir l'impunité informationnelle. Un réseau peut conserver le droit de rejeter toute route, mais s'il présente le rejet comme une application du RPKI, il devrait être en mesure de montrer quel état et quelle politique l'ont produit. Cette divulgation minimale préserve une responsabilité précise sans forcer le transport.

Une correction n'est pas complète lorsque la ROA change

La chaîne opérationnelle est asynchrone. Un détenteur peut corriger une ROA dans un portail et rester inaccessible. Le nouvel objet doit être généré et publié. Les clients du dépôt doivent le récupérer. Les validateurs doivent authentifier une vue actuelle cohérente et modifier leur ensemble de charges utiles. Les caches doivent notifier ou attendre l'interrogation du routeur. Les routeurs doivent recevoir l'ajout ou le retrait, recalculer l'état de validation et réappliquer la politique. Les voisins peuvent avoir besoin d'une réévaluation si les chemins ont été supprimés. Le trafic doit ensuite reconverger.

Chaque étape peut réussir tandis que le résultat final reste cassé. Le RIR peut montrer un objet corrigé dans son dépôt pendant qu'un validateur est incapable de récupérer le point de publication. Un validateur peut montrer la bonne charge utile pendant qu'un routeur est bloqué sur un cache préféré défaillant. Le routeur peut mettre à jour l'état mais conserver un résultat politique calculé avant le changement. Un cluster frontalier peut récupérer tandis qu'un autre a des données expirées. Un fournisseur peut restaurer l'importation mais continuer à supprimer l'exportation vers les pairs.

Pour cette raison, la mesure de service significative n'est pas « le temps de confirmation du portail ». C'est le temps entre la demande de correction authentifiée et la restauration observée à travers des points de contrôle déclarés. Les points de contrôle n'ont pas besoin d'inclure tous les réseaux de la Terre. Ils devraient inclure la publication de l'émetteur, au moins deux vues de validation indépendantes (si disponibles), l'état du cache et du routeur du fournisseur affecté, et des collecteurs BGP externes représentatifs ou des sondes client.

Le RFC 9324 ajoute une leçon de récupération importante. Si un routeur a supprimé les chemins Invalid et n'a pas conservé suffisamment d'état avant politique, de nouvelles données RPKI peuvent provoquer des demandes de rafraîchissement de route aux voisins. À grande échelle, cela a causé une charge sérieuse et même le dépeering. Conserver les chemins affectés pour une réévaluation locale n'est donc pas seulement une amélioration de performance; cela fait partie d'un droit de correction. L'autorisation d'un détenteur ne peut pas être réparée rapidement si le réseau a oublié la route et n'a aucun moyen sûr de la récupérer.

La chaîne explique aussi pourquoi des délais mondiaux fixes peuvent induire en erreur. La fréquence de publication, la santé du dépôt, l'interrogation du validateur, les minuteries du cache, l'architecture du routeur et la convergence BGP diffèrent. La gouvernance devrait spécifier des objectifs mesurables à des étapes contrôlées et rapporter la restauration observée de bout en bout, plutôt que de promettre un instant universel impossible.

Un reçu de correction devrait inclure les identifiants d'objet anciens et nouveaux, l'heure de publication, les premières heures vues par le validateur, le changement de charge utile, la première heure d'application par le routeur, la méthode de réévaluation de route et les observations externes. Cela crée un enregistrement pour l'amélioration post-incident et pour tout litige sur l'institution qui a retardé la récupération.

Cinq cas d'échec révèlent cinq acteurs responsables différents

Considérons d'abord une ROA incorrecte créée à partir d'une instruction authentifiée du détenteur. Si le détenteur a saisi la mauvaise origine ou la mauvaise longueur maximale et que le registre l'a traitée avec précision, le devoir de correction primaire incombe au détenteur, tandis que le registre doit encore des contrôles de modification utilisables et des outils d'avertissement. Si le portail a transformé une instruction correcte de manière incorrecte, la responsabilité se déplace vers l'opérateur de service. Le routeur qui rejette la route Invalid qui en résulte a appliqué sa politique déclarée; il n'a pas créé la mauvaise autorisation.

Deuxièmement, considérons une erreur de certificat de registre ou de publication qui supprime une charge utile valide. Les validateurs peuvent être d'accord parce qu'ils traitent fidèlement le même état amont. Leur accord n'absout pas l'émetteur; il localise la cause. Les opérateurs décident toujours si des exceptions d'urgence sont appropriées, mais le registre doit une restauration rapide, des raisons et des preuves préservées.

Troisièmement, supposons que deux validateurs sont en désaccord parce que l'un a des données de dépôt obsolètes ou un défaut logiciel. L'opérateur du cache devrait isoler la différence d'entrée, et le mainteneur du logiciel devrait corriger un défaut reproductible. Le réseau doit décider quelle vue utiliser pendant le désaccord. Une simple majorité ne suffit pas; deux instances obsolètes peuvent surpasser une instance actuelle. La décision devrait considérer la fraîcheur, les entrées de confiance, les preuves d'objet et l'indépendance des défaillances.

Quatrièmement, supposons que la connexion cache-routeur échoue jusqu'à ce que les données expirent. Le RFC 8210 empêche la conservation indéfinie, mais il ne choisit pas la politique de routage ultérieure du réseau. Le service de cache est responsable de la disponibilité dans le cadre de son engagement. L'opérateur est responsable de la redondance, de la gestion des expirations et de savoir si la perte de validation échoue en ouvert ou en fermé. Un vendeur est responsable si l'implémentation contredit un comportement configuré ou normalisé.

Cinquièmement, supposons qu'une charge utile correcte atteigne le routeur mais qu'un terme de politique soit ordonné incorrectement, appliqué seulement à certaines sessions ou hérité d'une valeur par défaut du vendeur. C'est une défaillance de configuration de l'opérateur, peut-être assistée par des diagnostics inadéquats du vendeur. Le registre ne peut pas réparer cela. Les preuves doivent inclure la version de la politique, la portée de la session et le résultat de la table de route, pas seulement une capture d'écran d'une charge utile Valid.

Ces exemples montrent pourquoi une seule catégorie large « incident RPKI » est inadéquate. Le même symptôme visible — un préfixe inaccessible — peut provenir de l'autorisation, de la validation, de la distribution, de la classification ou de la politique. L'examen d'incident devrait attribuer la première transition d'état incorrecte et tout devoir de confinement ou de récupération échoué. Plusieurs acteurs peuvent être responsables de différentes parties sans que la responsabilité devienne dénuée de sens.

Les droits et recours doivent être exécutoires à la frontière où le préjudice se produit

Une charte de gouvernance n'est utile que si une partie affectée peut l'invoquer. Le détenteur a besoin d'une voie d'urgence authentifiée vers le service de certification, d'un moyen de voir les modifications en attente et publiées, et d'un reçu durable. Il a besoin d'une raison lorsque l'autorité est retirée et d'une voie pour contester les erreurs ou les actions défavorables. Pour une erreur courante du détenteur, l'autocorrection en libre-service peut suffire. Pour une révocation contestée ou une contrainte légale, un examen indépendant et des arrangements de continuité deviennent plus importants.

Le client de l'opérateur a besoin d'un recours différent. Il devrait pouvoir demander pourquoi une route a été rejetée et recevoir une réponse liée à l'observation du fournisseur. Le fournisseur devrait divulguer l'état de validation, l'heure du cache, la charge utile couvrante et la classe de politique pertinente sans exposer des détails de sécurité réseau non liés. Il devrait offrir une procédure d'exception temporaire étroitement contrôlée là où le risque commercial et sécuritaire le permet, mais aucun client ne devrait supposer un droit inconditionnel de forcer la propagation.

L'opérateur a aussi besoin de droits contre son cache ou son fournisseur de validation géré. Les conditions de service devraient identifier les ancres de confiance, le logiciel, les cibles de mise à jour, le comportement des données obsolètes, les notifications, la conservation des journaux et le support en cas de divergence. Si un fournisseur combine validation et recommandations de routage, il devrait séparer les changements de charge utile factuels de ses conseils politiques. Le client doit rester capable de comprendre et de remplacer le choix de routage final.

Les vendeurs de routeurs doivent un contrôle implémentable. Les opérateurs ont besoin de commandes et de télémétrie qui distinguent la validation de l'action, montrent les sessions de cache et les âges, conservent ou récupèrent les chemins affectés en toute sécurité, et exposent pourquoi un terme de politique a correspondu. Les valeurs par défaut devraient être documentées et les mises à niveau ne devraient pas modifier silencieusement le traitement des routes Invalid ou NotFound. Un défaut reproductible devrait avoir une réponse de sécurité et un enregistrement de version.

Les recours devraient être proportionnés. La correction technique immédiate est généralement plus précieuse que des dommages spéculatifs. L'avis, l'état préservé, le retrait ou le remplacement rapide, la réévaluation et la vérification externe viennent en premier. Des recours financiers ou contractuels peuvent suivre lorsqu'une faute contrôlée et une perte documentée subsistent, mais une responsabilité illimitée découragerait l'infrastructure partagée et ne pourrait pas refléter les nombreuses décisions indépendantes entre le certificat et le paquet.

Le minimum exécutoire n'est donc pas une garantie d'accessibilité universelle. C'est un droit à la preuve et à une action rapide de la part de l'institution contrôlant l'étape contestée. Ce droit transforme une dépendance technique diffuse en une série de services responsables.

Les reçus de décision rendent l'autorité distribuée vérifiable

Le RPKI contient déjà des objets signés et des règles de validation soigneusement spécifiées. Ce qui manque souvent à la frontière de l'opérateur, c'est un enregistrement compact reliant ces objets à une conséquence de routage. Un reçu de décision ne serait pas une nouvelle autorisation globale. Ce serait un format de preuve produit par chaque acteur pour sa propre action.

À la couche de certification, le reçu devrait identifier la ressource, l'autorisation ancienne et nouvelle, l'identité du demandeur, la méthode d'approbation, l'heure de publication effective, la catégorie de raison et toute référence d'appel ou d'urgence. Les détails personnels sensibles peuvent rester protégés tandis que le changement au niveau de l'objet et la base d'autorité sont visibles.

À la couche de validation, il devrait enregistrer le logiciel et la version, les ancres de confiance actives, les modifications locales, l'instantané du dépôt ou l'heure d'observation, le résultat de validation, l'ajout ou le retrait de charge utile et tout avertissement pertinent. À la couche cache-routeur, il devrait ajouter l'identité du cache, la version du protocole, l'identifiant de session, le numéro de série, la fin du transfert et l'âge des données. Ces détails transforment « mon validateur dit autre chose » en une comparaison reproductible.

À la couche de routeur, le reçu devrait nommer la route, la classe de pair, l'état de validation, le terme de politique correspondant, l'action résultante, la version de la politique et l'heure. Si une route a été conservée mais inéligible, l'enregistrement devrait le dire. Si une exception s'est appliquée, elle devrait inclure la portée, l'approbateur et l'expiration. Pour un grand fournisseur, les enregistrements peuvent être générés automatiquement et divulgués sélectivement en réponse à des demandes légitimes.

L'observation externe complète la chaîne. RIPE RIS, RouteViews et les looking glasses des opérateurs peuvent montrer si les annonces sont apparues de points de vue sélectionnés. Ils ne peuvent pas prouver ce que chaque réseau a accepté, et l'absence à un collecteur n'est pas une preuve de suppression mondiale. Leur valeur est une preuve temporelle indépendante: la route était visible ici avant le changement, absente ici après et restaurée ici à une heure enregistrée.

Les reçus devraient utiliser des identifiants stables sans prétendre que les numéros de série de différents caches sont directement comparables. Ils devraient préserver les horodatages bruts et marquer clairement l'inférence. Un tableau de bord central peut les agréger, mais la preuve sous-jacente doit rester attribuable à l'acteur qui l'a produite.

Cette pratique change les incitations. Les registres améliorent les enregistrements de modification parce que les effets en aval peuvent être tracés. Les validateurs améliorent les diagnostics parce que les différences deviennent révisables. Les opérateurs testent la politique parce qu'ils peuvent avoir à expliquer un rejet. Les détenteurs maintiennent les ROA parce que leurs propres instructions restent visibles. La responsabilité émerge de preuves liées plutôt que de l'installation d'une nouvelle autorité au-dessus de tous les entités.

La mesure doit respecter ce qui peut et ne peut pas être observé

Les affirmations sur le déploiement sont souvent affaiblies par des dénominateurs ambigus. Compter les ROA valides mesure la publication d'autorisation, pas le nombre de réseaux rejetant les routes Invalid. Compter les réseaux qui semblent filtrer une annonce expérimentale n'établit pas leur politique pour chaque client, pair et région. Compter les vendeurs de routeurs avec une fonctionnalité RPKI ne montre pas que les opérateurs l'ont activée correctement.

Un programme de mesure utile sépare au moins quatre quantités. Premièrement, la couverture de publication: espace d'adressage ou préfixes routés couverts par des charges utiles validées, avec un traitement explicite des autorisations chevauchantes et des longueurs maximales. Deuxièmement, la disponibilité et la cohérence du validateur: si des validateurs indépendants sélectionnés dérivent le même ensemble de charges utiles à partir d'entrées de confiance identifiées. Troisièmement, le déploiement de la politique de routeur: si les réseaux observés semblent rejeter, dé-préférer ou propager des annonces Valid, Invalid et NotFound contrôlées.

Quatrièmement, la conséquence: quels préfixes et chemins ont changé lors d'un événement d'autorisation réel.

RIPE RIS et RouteViews offrent une visibilité BGP large mais échantillonnée via des pairs et collecteurs volontaires. Leurs archives peuvent soutenir l'analyse avant-après, mais elles ne voient pas chaque chemin bilatéral ou politique interne. Les expériences actives peuvent révéler le traitement le long des chemins testés, mais la propagation des routes, les relations commerciales et les changements de chemin peuvent confondre l'attribution. Les attestations d'opérateurs ajoutent du contexte mais peuvent décrire une politique prévue plutôt que réelle.

La réponse correcte n'est pas d'abandonner la mesure. C'est de publier les points d'observation, la fenêtre de temps, l'état de route testé, la confiance et les limitations. Une observation répétée de divers collecteurs peut identifier des tendances et des incidents sans inventer un pourcentage mondial exact. Les preuves devraient distinguer « non observé » de « rejeté » et « inférence au niveau AS » de « configuration au niveau routeur ».

Pour les audits de correction, la mesure peut être plus étroite et plus forte. Le fournisseur concerné peut exposer son cache et son enregistrement de politique; des validateurs indépendants peuvent montrer la convergence des charges utiles; des collecteurs de routes peuvent montrer la réapparition externe; des sondes de point final peuvent tester l'accessibilité. Cela ne prouve pas une réparation universelle, mais cela peut prouver la chaîne opérationnelle pour les parties impliquées.

Une Société des ressources numériques pourrait maintenir des définitions de mesure communes et publier des études d'événements reproductibles. Elle devrait résister aux classements basés sur des dénominateurs incomparables. Le but est de montrer où l'autorité et l'implémentation divergent, pas d'attribuer un seul score de vertu aux registres ou aux opérateurs.

Un rôle limité de Société des ressources numériques peut combler le vide institutionnel

Le fossé entre la publication du RIR et l'action du routeur invite soit à la résignation, soit à la centralisation. La résignation dit que chaque réseau est autonome, donc aucune responsabilité commune n'est possible. La centralisation dit qu'une seule institution devrait dicter le traitement de chaque état de validation. Les deux réponses sont trop faciles.

Une Société des ressources numériques peut occuper une position plus étroite. Elle peut définir des formats de reçu de décision, comparer les engagements de correction des registres, tester les validateurs par rapport à des instantanés identifiés, publier des exercices de récupération cache-routeur et aider les petits opérateurs à interpréter le comportement des vendeurs. Elle peut rassembler les détenteurs, les RIR, les fournisseurs de transit, les opérateurs d'échange, les vendeurs et les chercheurs autour de preuves qui traversent les frontières organisationnelles.

Elle peut aussi exploiter un annuaire d'escalade. Un détenteur confronté à un rejet devrait pouvoir trouver le bon contact d'urgence du registre, le mainteneur du validateur, le bureau de routage du fournisseur et le propriétaire du service d'échange. Des champs de cas standardisés éviteraient la traduction répétée des preuves de préfixe, d'origine, de charge utile et de timing. Des cas agrégés pourraient révéler des erreurs récurrentes de maxLength, des modèles de cache obsolète ou des défauts d'ordre de politique sans exposer les données privées des clients.

La Société ne devrait pas signer des ROA de remplacement pour des ressources qu'elle n'administre pas, forcer le transport ou déclarer un titre contesté par préférence institutionnelle. Elle ne devrait pas transformer une meilleure pratique volontaire en une règle mondiale cachée. Sa légitimité viendrait de méthodes transparentes, d'une représentation équilibrée, de limitations publiées et de la valeur pratique d'une correction plus rapide.

Elle ne devrait pas non plus certifier qu'un réseau est « conforme RPKI » par un questionnaire unique. L'assurance devrait être basée sur les événements. Le réseau peut-il montrer l'âge du cache? Un changement de charge utile déclenche-t-il une réévaluation sûre? Un client peut-il obtenir un avis de rejet motivé? Une exception expire-t-elle? Le désaccord entre deux validateurs peut-il être expliqué? La correction du registre devient-elle visible extérieurement dans l'intervalle rapporté?

Ces tests préservent l'autonomie tout en la rendant responsable. Les RIR conservent la responsabilité de certification. Les opérateurs conservent la responsabilité de routage. Les vendeurs conservent la responsabilité d'implémentation. La Société fournit des preuves et un examen communs là où les relations bilatérales sont trop fragmentées pour le faire efficacement.

Le cas positif pour une telle institution est le plus fort pour les réseaux ayant le moins de pouvoir de négociation. Les grands opérateurs peuvent construire leur propre télémétrie et appeler directement les ingénieurs du registre. Les petits détenteurs et les fournisseurs régionaux ne le peuvent souvent pas. Des procédures partagées peuvent leur donner un recours crédible sans prétendre qu'ils ont le droit de dicter la politique de chaque réseau distant.

La couche de gouvernance est une carte des frontières, pas un autre interrupteur

La vision mature du déploiement RPKI commence là où les diagrammes promotionnels se terminent souvent. Un objet signé atteint un validateur; une charge utile atteint un routeur; un état atteint une politique; une politique affecte une relation commerciale et un chemin de paquet. Chaque flèche est une interface technique et un transfert institutionnel.

La règle centrale reste claire. Les RIR et les détenteurs de ressources publient des déclarations d'autorité authentifiées. Les validateurs déterminent ce qui découle des données de confiance qu'ils peuvent valider. Les routeurs classifient les routes et exécutent des contrôles configurés. Les opérateurs réseau décident du traitement final. Les normes empêchent délibérément que la politique automatique soit introduite subrepticement dans la classification.

Cette division ne devrait pas devenir une chaîne de désengagements. L'émetteur doit répondre de l'émission et de la publication. L'opérateur du validateur et du cache doit répondre du calcul et de la distribution fidèles et opportuns. Le vendeur doit répondre de l'implémentation. Le réseau doit répondre de la politique, de l'exception et de la récupération. Les services de transit et de peering doivent expliquer les conditions dans lesquelles les contrôles partagés affectent les autres.

Trois réformes rendraient l'arrangement gouvernable. Premièrement, publier des reçus de décision qui connectent les changements d'objet à l'état du validateur, du cache et du routeur. Deuxièmement, fournir des procédures de correction et de contestation exécutoires à chaque frontière contrôlée. Troisièmement, mesurer les événements de bout en bout avec des points d'observation déclarés plutôt que de substituer des comptes d'adoption à une preuve opérationnelle.

Le résultat n'éliminerait pas les incidents de routage ou les désaccords sur l'autorité. Il les rendrait traitables. Un détenteur affecté pourrait identifier le premier état incorrect, l'institution capable de le réparer et les preuves nécessaires pour vérifier la récupération. Un opérateur pourrait défendre une décision de sécurité sans prétendre qu'un label Invalid prouve un motif. Un registre pourrait accepter la responsabilité de son propre acte sans devenir un assureur de chaque choix de routage.

La couche de gouvernance manquante n'est donc pas un code manquant. C'est une lisibilité manquante. L'architecture RPKI-routeur laisse déjà le choix final aux opérateurs autonomes. La tâche institutionnelle à partir de 2018 est de s'assurer que cette autonomie reste visible, raisonnée et révisable plutôt que cachée derrière un état de validation vert, gris ou rouge.

Sources

  • RFC 8481: Clarifications à la validation d'origine BGP basée sur le RPKI— Établit la règle de 2018 selon laquelle la validation définit l'état tandis que la configuration de l'opérateur contrôle la politique. Il ne prescrit pas un traitement préféré pour chaque classe de pair ou incident.
  • RFC 8210: Le protocole RPKI vers routeur, version 1— Définit les sessions cache-routeur, les mises à jour séquentielles, les annonces et retraits de charges utiles, les options de transport, et les paramètres d'actualisation, de nouvelle tentative et d'expiration. Il spécifie la livraison de données plutôt que des obligations de routage commercial.
  • RFC 6811: Validation d'origine de préfixe BGP— Définit la comparaison Valid, Invalid et NotFound et traite l'utilisation du résultat comme politique locale. Il n'identifie pas le motif derrière une divergence.
  • RFC 7115: Opération de validation d'origine— Fournit des conseils de déploiement et de politique de routage, y compris des avertissements sur les changements de trafic, la faible préférence et les routes plus spécifiques. Certaines hypothèses opérationnelles reflètent un stade d'adoption antérieur et ne doivent pas être lues comme des chiffres de déploiement actuels.
  • RFC 9324: Politique basée sur le RPKI sans rafraîchissement de route— Documente le comportement de rafraîchissement nuisible observé dans le déploiement et recommande de conserver les chemins affectés pour réévaluation. Il ne mesure pas chaque implémentation de vendeur ou de réseau.
  • RFC 8897: Exigences pour les parties prenantes RPKI— Consolide les exigences pour la récupération, la validation et la distribution des données RPKI. C'est une carte des exigences, pas un audit des services de validation privés actuels.
  • RFC 8416: Gestion locale simplifiée des ressources numériques Internet avec le RPKI— Définit les filtres et assertions locaux qui peuvent soutenir des exceptions limitées. Un tel état local ne modifie pas la vue signée globale pour les autres opérateurs.
  • RFC 8211: Actions défavorables par une autorité de certification— Analyse comment les actions de certificat et de dépôt peuvent nuire aux détenteurs et comment les contrôles locaux peuvent atténuer les effets. Il ne juge pas si une action de registre particulière est légalement justifiée.
  • Cisco: BGP RPKI avec IOS XR 7 sur Cisco 8000— Montre les correspondances de politique, la dé-préférence, le traitement du meilleur chemin et les choix de réévaluation dans une famille de produits. Les exemples n'établissent pas la pratique globale de l'opérateur.
  • Cisco IOS XE: Validation d'origine AS BGP— Documente les connexions cache et plusieurs résultats de politique pour les états de validation. Les commandes du produit ne doivent pas être généralisées à d'autres versions sans vérification.
  • Juniper Networks: Configuration du RPKI— Sépare le marquage d'état de la politique d'acceptation ou de rejet ultérieure et explique son placement sur les importations client, pair et transit. C'est un guide opérationnel plutôt qu'une étude de mesure indépendante.
  • Documentation BGP FRRouting— Démontre le traitement par route-map open-source des états Valid, Invalid et NotFound et la télémétrie cache. Le comportement dépend de la version et de la configuration locale.
  • Documentation RIPE RIS— Décrit une plateforme distribuée de collecte BGP et ses données brutes. La visibilité du collecteur est échantillonnée et ne peut pas prouver le traitement de chaque réseau.
  • Documentation de l'API RouteViews— Décrit les vues actuelles et archivées des collecteurs entités. L'absence d'un collecteur n'est pas, en soi, une preuve qu'une route a été rejetée mondialement.
  • Charte NRS— Fournit un soutien normatif pour la participation distribuée et les limites au pouvoir concentré sur les ressources numériques. Les fonctions d'assurance, de reçu et d'escalade proposées ici sont des recommandations, pas une preuve de déploiement universel actuel.