L'Internet dépend d'un système de routage mondial qui permet aux réseaux, centres de données, plateformes cloud, fournisseurs de services Internet et entreprises d'échanger du trafic. L'un des protocoles les plus importants dans ce système est le Border Gateway Protocol, communément appelé BGP. BGP permet aux réseaux indépendants d'annoncer les plages d'adresses IP qu'ils peuvent atteindre. Sans BGP, l'Internet moderne ne serait pas en mesure de connecter des millions de réseaux à travers différents pays et fournisseurs. Cependant, BGP a été initialement conçu pour échanger des informations de routage sur la base de la confiance. Lorsqu'un réseau annonce un préfixe IP, d'autres réseaux peuvent accepter cette annonce sans disposer d'une méthode cryptographique solide pour confirmer si ce réseau est réellement autorisé à utiliser le préfixe. Cela crée un problème de sécurité. Une annonce de route incorrecte ou malveillante peut rediriger le trafic, interrompre des services ou exposer des données à des chemins non désirés.
Le RPKI a été développé pour améliorer la sécurité du routage Internet. Le nom signifie Infrastructure de clés publiques des ressources. Il offre un moyen de relier les ressources numériques d'Internet, telles que les préfixes IPv4 et IPv6, avec le numéro de système autonome autorisé à les originer. Les opérateurs réseau peuvent ensuite utiliser ces informations pour déterminer si une annonce BGP est cohérente avec l'autorisation enregistrée.
Pour les entreprises exploitant leur propre ASN, gérant des ressources IP, utilisant plusieurs fournisseurs en amont ou prévoyant d'annoncer des espaces IPv4 ou IPv6, la compréhension du RPKI devient de plus en plus importante. Le RPKI ne remplace pas BGP et ne résout pas tous les problèmes de routage. Il fournit plutôt une couche supplémentaire de vérification qui aide les réseaux à prendre des décisions de routage plus sûres.
Qu'est-ce que le RPKI ?
Le RPKI est un cadre de sécurité qui utilise des certificats numériques et des enregistrements cryptographiques pour vérifier la relation entre un préfixe d'adresse IP et un ASN d'origine. Un préfixe IP est un bloc d'adresses, tel qu'un IPv4 /24 or an IPv6 /48. Un ASN identifie un réseau indépendant qui participe au routage BGP.
L'idée de base est simple. Une organisation autorisée à utiliser un préfixe IP publie une déclaration signée indiquant quel ASN est autorisé à annoncer ce préfixe dans BGP. Les réseaux qui reçoivent des annonces BGP peuvent comparer l'annonce aux informations publiées. Si l'annonce correspond, elle peut être considérée comme autorisée. Si elle est en conflit avec les informations, l'annonce peut être considérée comme suspecte ou invalide.
Les enregistrements utilisés pour exprimer cette autorisation sont communément appelés des Route Origin Authorizations, ou ROA. Une ROA identifie un préfixe IP, un ASN d’origine autorisé et, le cas échéant, la longueur maximale du préfixe que l’ASN est autorisé à annoncer. Bien que les ROA constituent une partie importante du RPKI, cet article se concentre sur l’objectif plus large du RPKI et sur la manière dont il améliore la sécurité du routage.
Le RPKI est généralement géré par les Registres Internet Régionaux, y compris le RIPE NCC, l'ARIN, l'APNIC, le LACNIC et l'AFRINIC. Selon la région et le type de ressource, le détenteur des ressources ou l'organisation parrainante peut créer et gérer les enregistrements d'autorisation pertinents via les systèmes du registre.
Pourquoi le BGP a-t-il besoin de RPKI ?
Le BGP a été créé à une époque où Internet était plus petit et le nombre de réseaux participants limité. Son objectif principal était d’échanger des informations de reachabilité entre systèmes autonomes. Le BGP peut sélectionner des chemins en fonction de politiques, de la longueur du chemin, de la préférence locale et d’autres attributs, mais le protocole lui-même ne vérifie pas automatiquement si un ASN est autorisé à originer un préfixe IP particulier.
Cela signifie qu'une erreur de configuration peut parfois ressembler à une annonce malveillante. Si un réseau annonce accidentellement un préfixe appartenant à une autre organisation, d'autres réseaux peuvent initialement accepter la route. Le résultat peut être un trafic dirigé vers la mauvaise destination, une perte de connectivité ou une instabilité du routage.
Un exemple bien connu est une fuite de route ou un détournement de préfixe. Dans un détournement, un ASN annonce un préfixe qu'il ne contrôle pas ou qu'il n'est pas censé originer. L'annonce peut être plus spécifique que la route légitime, ou elle peut atteindre suffisamment de réseaux pour affecter le trafic. Même lorsque l'incident est accidentel, l'impact opérationnel peut être significatif.
Le RPKI aide en fournissant aux opérateurs de réseau une source externe d’informations d’autorisation. Au lieu de se fier uniquement au contenu d’une annonce BGP, un routeur ou un système de sécurité du routage peut vérifier si l’ASN d’origine a été autorisé par le titulaire de l’espace d’adresses. Cela ne prévient pas tous les incidents de routage, mais il rend plus facile l’identification et le filtrage d’une classe importante d’erreurs de routage.
Comment fonctionne le RPKI ?
Le RPKI fonctionne par une chaîne de confiance. Les ressources numériques d'Internet sont gérées par les Registres Internet Régionaux, et ces registres fournissent la base pour les certificats numériques pertinents. Le titulaire d'une ressource IP peut créer un enregistrement d'autorisation indiquant quel ASN peut originer le préfixe.
Les enregistrements signés sont collectés dans des dépôts qui peuvent être consultés par le logiciel de sécurité de routage. Un opérateur de réseau exécute un validateur RPKI ou utilise un service qui effectue la validation en son nom. Le validateur télécharge les enregistrements disponibles, vérifie leurs signatures, contrôle s'ils sont à jour et produit un jeu de données validé.
L'ensemble de données validé est ensuite connecté à l'infrastructure de routage du réseau. Lorsqu'une route BGP est reçue, le routeur ou le système de politique de routage compare le préfixe annoncé et l'ASN d'origine avec les informations RPKI validées. Le résultat est généralement classé comme Valide, Non valide ou Non trouvé.
Ce processus se déroule indépendamment de la session BGP elle-même. BGP continue d’échanger des informations de routage, tandis que RPKI fournit des données d’autorisation supplémentaires qui peuvent être utilisées dans la politique de routage. Un réseau peut décider comment gérer chaque résultat de validation. Par exemple, il peut rejeter les routes Invalides, leur attribuer une préférence inférieure ou générer des alertes pour examen ultérieur.
Le processus est conçu pour être distribué et évolutif. Les grands réseaux peuvent valider des milliers de préfixes sans qu'il soit nécessaire que chaque organisation établisse une relation directe avec tous les autres réseaux. Cela est important car Internet comprend un très grand nombre d'opérateurs indépendants ayant des politiques et des environnements techniques différents.
Qu'est-ce qu'une autorisation d'origine de route ?
Une autorisation d'origine de route est un enregistrement signé indiquant quel ASN est autorisé à originer une préfixe IP spécifique. Il s'agit de l'une des parties les plus visibles et pratiques du déploiement de RPKI.
Par exemple, une organisation peut contrôler le préfixe IPv4 192.0.2.0/24 et utiliser ASN AS64500 pour l'annoncer. L'organisation peut créer une autorisation qui permet AS64500 provenir 192.0.2.0/24Si un autre ASN annonce ultérieurement le même préfixe, les réseaux effectuant une validation RPKI peuvent détecter que l'origine ne correspond pas à l'autorisation.
L'autorisation peut également spécifier une longueur maximale de préfixe. Cela est important car un réseau peut souhaiter autoriser l'ASN d'origine à annoncer le préfixe agrégé exact, mais pas des préfixes plus spécifiques et plus courts. Une longueur maximale soigneusement sélectionnée peut réduire le risque qu'une annonce inattendue soit considérée comme autorisée.
La configuration ROA nécessite une attention particulière, car un enregistrement incorrect peut rendre une route légitime invalide. Si une organisation change de fournisseur de transit, déplace un préfixe vers un ASN différent, divise une annonce en préfixes plus spécifiques ou transfère des ressources à un autre détenteur, les enregistrements d'autorisation peuvent devoir être mis à jour. Un enregistrement obsolète peut provoquer une panne même lorsque la configuration BGP elle-même est correcte.
Un article futur pourra expliquer comment créer un ROA, comment choisir une longueur maximale et comment mettre à jour les autorisations lors d'une migration de ressources ASN ou IP.
Que signifient Valide, Non valide et Introuvable ?
Un résultat « Valid » signifie qu'une annonce BGP est couverte par une autorisation RPKI applicable et que l'ASN d'origine est autorisé à annoncer le préfixe. Il indique généralement que le préfixe annoncé, la longueur du préfixe et l'ASN d'origine sont cohérents avec l'autorisation publiée.
Un résultat invalide signifie qu'une autorisation existe, mais que l'annonce BGP ne s'y conforme pas. Cela peut se produire parce que l'ASN d'origine n'est pas autorisé, parce que l'annonce est plus spécifique que la longueur maximale autorisée, ou parce que le préfixe chevauche une autorisation pour une origine différente. Les routes invalides méritent une attention immédiate car elles peuvent représenter un détournement de trafic (hijack), une configuration accidentelle ou une migration incomplète.
Un résultat « Not Found » signifie qu’aucune autorisation applicable n’a été trouvée pour l’annonce. Cela ne signifie pas automatiquement que la route est malveillante ou incorrecte. Cela signifie simplement que le RPKI ne peut pas confirmer l’origine à l’aide des enregistrements actuellement publiés. De nombreuses routes légitimes restent dans cet état car le détenteur des ressources n’a pas créé d’autorisation.
La distinction entre Invalid et Not Found est importante. Invalid indique un conflit avec les données d'autorisation existantes, tandis que Not Found indique une absence de données d'autorisation. Les opérateurs de réseau traitent souvent les routes Invalid plus sérieusement, mais leur politique de routage exacte dépend de leur tolérance au risque, de leurs exigences en matière de service et de leurs procédures opérationnelles.
Why RPKI Matters for IPv4 Networks
L'espace d'adressage IPv4 est limité, et de nombreux préfixes IPv4 sont désormais utilisés dans le cadre d'arrangements complexes impliquant des fournisseurs, des centres de données, des plateformes cloud, des sociétés de location et des transactions de transfert. Ces arrangements rendent la précision du routage particulièrement importante.
Lorsqu'un préfixe IPv4 est transféré ou déplacé entre organisations, l'origine BGP peut également changer. Si l'autorisation du précédent propriétaire reste active tandis que le nouveau propriétaire annonce le préfixe depuis un ASN différent, la route peut devenir invalide au regard de RPKI. C'est l'une des raisons pour lesquelles la planification RPKI doit être intégrée aux travaux de transfert et de migration d'IPv4.
Avant d'accepter ou d'annoncer une préfixe IPv4, une organisation doit confirmer quelle entité contrôle la ressource, quel ASN est censé l'originer, et si les enregistrements d'autorisation pertinents reflètent la conception de routage prévue. L'enregistrement du registre public, les annonces BGP et les informations RPKI doivent être examinés conjointement. Le RPKI est particulièrement utile lorsqu'une entreprise utilise plusieurs fournisseurs de transit. Une autorisation d'origine cohérente peut protéger le préfixe indépendamment du fournisseur amont qui transporte la route. Cependant, l'organisation doit toujours s'assurer que tous les fournisseurs utilisent le bon ASN et la bonne longueur de préfixe.
Les entreprises évaluant un bloc IPv4 peuvent également utiliser des outils publics pour examiner les données d'enregistrement actuelles, les informations sur l'ASN d'origine, le statut RPKI et la visibilité BGP. Ces vérifications ne remplacent pas la diligence raisonnable contractuelle ou le screening de réputation, mais elles peuvent révéler des incohérences évidentes dans le routage avant une transaction ou un déploiement.
Why RPKI Matters for IPv6 Networks
Les réseaux IPv6 bénéficient des mêmes principes de validation d'origine que les réseaux IPv4. Les préfixes IPv6 sont annoncés via BGP, et une origine incorrecte peut créer des risques similaires, notamment des interruptions de trafic, des fuites de routes et des annonces non autorisées.
Les déploiements IPv6 impliquent souvent des blocs d’adresses plus larges et des plans d’adressage plus structurés. Une organisation peut recevoir une allocation étendue et annoncer un agrégat tout en utilisant de plus petits sous-réseaux internes pour les sites, les centres de données ou les services. L’autorisation RPKI doit correspondre aux préfixes qui sont effectivement destinés au routage public.
Une erreur courante consiste à supposer que le routage IPv6 est automatiquement plus sûr en raison de l'espace d'adressage beaucoup plus vaste. La taille de cet espace ne supprime pas la nécessité de vérifier l'origine des routes. Si un préfixe IPv6 est annoncé par une ASN incorrecte et qu'aucune autorisation n'existe, les autres réseaux peuvent avoir une capacité limitée à distinguer cette annonce d'une route légitime. Les organisations déployant IPv6 devraient intégrer RPKI dès leur conception initiale du routage plutôt que d'attendre que le réseau soit pleinement opérationnel. Cela facilite la coordination du plan d'adressage, de l'utilisation des ASN, des fournisseurs amont et des enregistrements d'autorisation avant que le trafic de production ne dépende de l'annonce.
Quels sont les principaux avantages du RPKI ?
Le principal avantage du RPKI est qu'il fournit une méthode largement reconnue pour valider l'origine d'une route BGP. Cela donne aux opérateurs de réseau une base plus solide pour filtrer et surveiller les annonces que les informations BGP seules.
Le RPKI peut réduire le risque d’accepter des routes manifestement incompatibles avec l’autorisation déclarée du détenteur de ressources. Il permet également d’identifier les erreurs opérationnelles lors des migrations réseau, des changements de fournisseur, des modifications de parrainage ASN et des transferts de ressources IPv4 ou IPv6.
Pour les détenteurs de ressources IP, le RPKI démontre que l'organisation gère activement la sécurité du routage de son espace d'adresses. Cela peut améliorer la coordination avec les fournisseurs de transit et réduire les confusions lorsque plusieurs parties sont impliquées dans l'annonce du même préfixe.
Pour les fournisseurs de transit et les entreprises d’hébergement, la validation RPKI peut faire partie d’un programme plus large de sécurité du routage. Les fournisseurs peuvent utiliser les résultats de la validation conjointement avec des filtres de préfixes, des données IRR, une surveillance BGP et des politiques de routage internes. Aucune source de données n’est parfaite, mais combiner plusieurs signaux offre une meilleure visibilité opérationnelle.
Le RPKI améliore également la gestion des incidents. Lorsqu'une annonce BGP inattendue apparaît, l'équipe réseau peut rapidement vérifier si l'origine est autorisée. Cela permet de distinguer un potentiel détournement (hijack) d'un changement de routage légitime mais non documenté.
Ce que le RPKI ne peut pas faire
Le RPKI est précieux, mais il ne constitue pas un remplacement complet de la sécurité du routage. Il valide la relation entre une préfixe et un ASN d'origine. Il ne prouve pas que chaque saut dans le chemin BGP est fiable, et il ne garantit pas que le trafic suivra la route physique la meilleure ou la plus sûre.
Le RPKI ne chiffre pas le trafic des applications. Il ne protège pas les sessions web, les requêtes DNS, les e-mails ou les données privées contre l'interception. Des technologies de chiffrement telles que TLS, les VPN et des protocoles d'application sécurisés restent nécessaires à ces fins.
Le RPKI ne prévient pas non plus automatiquement toutes les fuites de routes. Une route peut être originée par le bon ASN mais toujours propagée vers des endroits où elle ne devrait pas apparaître. La validation d'origine peut classer une telle route comme Valide car l'origine est autorisée, même si le chemin global est opérationnellement incorrect.
Le RPKI ne prouve pas à lui seul la propriété légale. Les registres, les contrats, les documents de transfert et l'autorisation organisationnelle restent importants. Un résultat « Valide » indique que la route correspond à une autorisation publiée ; il ne confirme pas que toutes les exigences commerciales ou légales ont été satisfaites.
Enfin, le RPKI ne fonctionne efficacement que lorsque les enregistrements sont maintenus. Une organisation qui crée des autorisations et oublie ensuite de les mettre à jour après un changement de fournisseur ou d'ASN peut provoquer sa propre panne de routage.
Comment une entreprise peut-elle commencer à utiliser le RPKI ?
La première étape consiste à créer un inventaire de tous les préfixes IPv4 et IPv6 que l'organisation possède, loue, parraine ou s'attend à annoncer. Pour chaque préfixe, notez l'ASN d'origine prévu, les fournisseurs annonçant le préfixe, la longueur du préfixe et si le préfixe est actuellement visible dans BGP.
L'étape suivante consiste à confirmer les enregistrements du registre et les ressources. L'organisation doit vérifier que l'espace d'adressage est associé au bon compte, à la bonne organisation, au LIR sponsor ou au détenteur de ressource. Si les données publiques d'enregistrement sont obsolètes, elles doivent être corrigées avant de créer de nouvelles autorisations de routage. Une fois l'inventaire des ressources confirmé, l'organisation peut créer les enregistrements d'autorisation appropriés via son Registre Internet régional ou son fournisseur sponsor. Le ASN d'origine et la longueur maximale du préfixe doivent refléter le plan de routage réel. Si plusieurs ASN sont légitimement utilisés, la conception doit être documentée soigneusement plutôt que d'ajouter des autorisations larges sans raison claire.
L'organisation doit ensuite valider les enregistrements à l'aide d'un validateur RPKI ou d'un service de surveillance établi. Il est important de confirmer que les annonces prévues retournent un résultat « Valide » avant d'appliquer des politiques de filtrage strictes au trafic client ou de production.
Le déploiement doit être considéré comme un processus opérationnel, et non comme une tâche de configuration ponctuelle. Les modifications apportées aux fournisseurs en amont, au parrainage ASN, à l'agrégation des préfixes, aux emplacements des centres de données et aux arrangements de transfert d'IPv4 peuvent toutes affecter les enregistrements RPKI. La surveillance et la gestion des changements doivent faire partie intégrante du flux de travail réseau normal.
Erreurs courantes lors du déploiement de RPKI
Une erreur courante consiste à créer une autorisation pour le mauvais ASN d'origine. Cela se produit souvent lors d'une migration de fournisseur lorsque l'ancien ASN reste dans l'enregistrement tandis que le réseau commence à être annoncé depuis un nouvel ASN.
Une autre erreur consiste à définir incorrectement la longueur maximale du préfixe. Si une organisation autorise uniquement un agrégat mais annonce une route plus spécifique, l'annonce de cette route plus spécifique peut devenir invalide. Si la longueur maximale est définie trop largement, l'autorisation peut permettre des annonces que l'organisation n'avait pas l'intention d'autoriser.
Les données obsolètes constituent également un problème majeur. Une autorisation qui était correcte il y a plusieurs années peut ne plus correspondre à la conception actuelle du réseau de l'organisation. Des examens réguliers sont particulièrement importants après un transfert IPv4, une fusion, un changement d'LIR sponsor ou une renumérotation ASN.
Certain organisations considèrent également qu’un résultat « Not Found » signifie qu’une route doit être rejetée. Dans la plupart des cas, « Not Found » signifie qu’il n’existe aucune autorisation. Cela devrait être traité conformément à la politique du réseau et au modèle de risque, plutôt que d’être considéré comme automatiquement malveillant.
RPKI, IRR et surveillance BGP
Le RPKI est l’un des éléments d’une approche plus large de la sécurité du routage. Les bases de données IRR contiennent des objets de politique de routage qui peuvent être utilisés par les opérateurs de réseau pour générer des filtres. Ces objets peuvent décrire quel ASN est censé originer un préfixe, mais ils reposent sur un modèle de confiance et de validation différent de celui du RPKI.
La surveillance BGP montre ce qui est réellement annoncé et où l'annonce est visible. Elle peut révéler des changements de routes, des origines inattendues, des modifications de chemin et des périodes d'instabilité. RPKI indique si l'origine est autorisée, mais ne fournit pas l'historique opérationnel complet d'une route.
Pour cette raison, RPKI, IRR et la surveillance BGP sont souvent utilisés conjointement. Une revue de routage rigoureuse peut comparer l’enregistrement du registre, l’ASN attendu, l’objet IRR, l’autorisation RPKI et les observations BGP en temps réel. Lorsque ces sources concordent, la position de routage est plus facile à comprendre. Lorsqu’elles divergent, il convient d’investiguer les écarts avant qu’une migration ou un transfert ne soit finalisé.
Comment le RPKI doit-il être maintenu ?
La maintenance du RPKI doit être intégrée à la gestion des changements réseau. Lorsqu'une organisation prévoit de modifier son ASN d'origine, son fournisseur en amont, sa longueur de préfixe ou son lieu d'annonce, elle devrait examiner l'effet attendu sur les enregistrements d'autorisation avant que le changement ne soit effectué.
La surveillance doit alerter l’équipe réseau lorsqu’un préfixe attendu devient invalide, qu’une autorisation est supprimée ou qu’une origine jamais vue auparavant apparaît. Les alertes sont plus utiles lorsqu’elles incluent le préfixe concerné, l’ASN de l’origine, l’état actuel de validation et l’heure du changement.
Les organisations devraient également documenter qui est responsable de la gestion du RPKI. Dans certaines entreprises, l'équipe d'ingénierie réseau gère les enregistrements. Dans d'autres, le LIR sponsorisant, le prestataire de services gérés ou l'équipe de sécurité s'en charge. Une propriété claire permet d'éviter les retards lors des incidents et des migrations de fournisseurs.
Une révision périodique peut être planifiée mensuellement, trimestriellement ou chaque fois qu'un changement majeur de routage se produit. La fréquence appropriée dépend de la taille et de la complexité du réseau. L'important est que le RPKI soit considéré comme une partie vivante du système de routage.
Questions fréquemment posées sur le RPKI
Le RPKI est-il requis pour utiliser BGP ?
Non. Un réseau peut utiliser BGP sans publier d'enregistrements d'autorisation RPKI. Cependant, RPKI est de plus en plus recommandé car il offre aux autres réseaux un moyen de valider l'origine des routes annoncées par l'organisation.
Le RPKI empêche-t-il un détournement BGP ?
Le RPKI n'empêche pas physiquement un autre réseau d'émettre une annonce BGP non autorisée. Il permet aux réseaux récepteurs d'identifier les annonces qui ne correspondent pas à l'autorisation publiée. Les réseaux peuvent ensuite rejeter, dépréférer ou surveiller ces routes conformément à leurs politiques.
Le RPKI est-il uniquement destiné à l'IPv4 ?
No. RPKI supports both IPv4 and IPv6 prefixes. The same basic origin validation concept applies to both address families.
Un résultat RPKI « Not Found » est-il dangereux ?
Pas nécessairement. « Not Found » signifie qu’aucune autorisation applicable n’a été trouvée. Cela ne prouve pas que la route est incorrecte. Toutefois, les détenteurs de ressources devraient publier des autorisations précises afin que d’autres réseaux puissent valider leurs annonces.
Le RPKI peut-il remplacer un objet de route IRR ?
Non. RPKI et IRR ont des objectifs différents et sont souvent utilisés conjointement. Certains fournisseurs utilisent ces deux systèmes lors de la création de filtres de routage et de l’examen des annonces.
Que se passe-t-il si un enregistrement RPKI est incorrect ?
Une erreur d'enregistrement peut entraîner la classification d'une annonce BGP légitime comme invalide. L'organisation doit examiner l'ASN d'origine, la longueur du préfixe et la longueur maximale, puis mettre à jour l'autorisation avant d'appliquer un filtrage strict des routes.
RPKI is an important improvement to the security of Internet routing. It gives IP resource holders a way to publish cryptographic authorization for the ASNs that are allowed to originate their IPv4 and IPv6 prefixes. It also gives network operators a practical method for checking whether BGP announcements match that authorization.
Le concept est simple : le détenteur d’un préfixe IP publie l’origine prévue, et les autres réseaux valident l’annonce par rapport à ces informations. Le résultat peut aider à identifier les routes autorisées, les routes conflictuelles, ainsi que les routes pour lesquelles aucune autorisation n’a été publiée. RPKI ne remplace pas une ingénierie réseau rigoureuse, la gestion des registres, les enregistrements IRR, la surveillance BGP ou la diligence raisonnable contractuelle. Il ne garantit pas non plus que chaque route soit sûre ou que tous les incidents de routage soient évités. Sa valeur réside dans l’ajout d’un signal d’autorisation fiable au processus de routage.
Pour les organisations gérant un ASN, un espace IPv4, un espace IPv6 ou plusieurs fournisseurs en amont, le RPKI doit être intégré à la conception normale du routage. Avant d'annoncer une préfixe, de changer de fournisseur, de finaliser un transfert IPv4 ou de déployer un nouveau réseau IPv6, il convient d'examiner conjointement les données du registre, l'ASN d'origine, les enregistrements d'autorisation et l'état BGP en direct. Ce processus simple peut prévenir des erreurs évitables et améliorer la fiabilité globale de la connectivité Internet.