La validation RPKI est maintenant une partie importante de la sécurité du routage BGP moderne. Elle permet aux opérateurs de réseau de déterminer si un numéro de système autonome est autorisé à annoncer un préfixe IPv4 ou IPv6 particulier. Lorsqu'un routeur reçoit une annonce de route, il peut comparer l'annonce avec l'autorisation RPKI publiée pour cette plage d'adresses.
Le résultat est généralement affiché comme Valide, Invalide ou Non trouvé. Ces trois étiquettes sont simples, mais elles sont souvent mal comprises. Un résultat Valide ne signifie pas que chaque partie du chemin est parfaite. Un résultat Invalide ne signifie pas toujours qu'une attaque est en cours sur le réseau. Un résultat Non trouvé ne signifie pas automatiquement que l'annonce est dangereuse.
Les étiquettes décrivent uniquement la relation entre une annonce BGP et les données d'autorisation d'origine de route disponibles. Pour comprendre correctement le résultat, vous devez comparer trois éléments : le préfixe IP annoncé, l'ASN d'origine et la longueur maximale de préfixe autorisée par l'autorisation.
Cet article explique chaque statut RPKI en termes pratiques, montre pourquoi les routes légitimes peuvent devenir Invalides, et fournit un processus de dépannage pour les opérateurs de réseau gérant leur propre ASN, leurs ressources IPv4, leurs allocations IPv6 ou leur routage en amont. Si vous êtes nouveau sur le sujet, commencez par notre guide vers Qu'est-ce que le RPKI ? et puis lire Qu'est-ce qu'un ROA dans RPKI ? pour une explication détaillée de l'enregistrement d'autorisation lui-même.
Qu'est-ce que la validation RPKI ?
RPKI signifie Infrastructure à clé publique des ressources. Elle relie les ressources numériques Internet aux enregistrements d'autorisation signés cryptographiquement. Le détenteur ou le gestionnaire autorisé d'un préfixe IP peut publier un ROA indiquant qu'un AS particulier est autorisé à originer ce préfixe dans BGP.
Un validateur collecte ces enregistrements signés, vérifie leur authenticité et crée un ensemble de données validé pour les opérateurs de réseau. Lorsqu'un chemin BGP est reçu, le système de routage de l'opérateur compare ce chemin à cet ensemble de données. La comparaison pose trois questions fondamentales : la préfixe annoncé est-il couvert par une autorisation ? Le ASN d'origine est-il celui indiqué dans cette autorisation ? La longueur du préfixe annoncé est-elle inférieure ou égale à la longueur maximale autorisée ?
La réponse à ces questions produit l'état RPKI. Cet état s'applique à l'autorisation d'origine des routes, et non à chaque attribut du chemin BGP. RPKI ne prouve pas que tous les réseaux intermédiaires sont corrects, que le trafic suivra le meilleur chemin, ou que les ressources d'adresses sont légalement disponibles pour la vente. C'est un signal de sécurité ciblé qui améliore la confiance dans l'origine d'une route.
Qu'est-ce que signifie RPKI valide ?
Un itinéraire est Valide RPKI lorsque l'annonce BGP est couverte par au moins une ROA applicable, l'ASN d'origine correspond à l'ASN autorisé, et la longueur du préfixe annoncé est autorisée par la longueur maximale de la ROA. En termes pratiques, la route est cohérente avec l'autorisation de routage publiée par le détenteur des ressources.
Par exemple, supposons qu'une entreprise contrôle 203.0.113.0/24 et publie un ROA autorisant AS64500 originer cela /24. Si la compagnie annonce 203.0.113.0/24 depuis AS64500, l'annonce devrait retourner Valide. C'est également vrai pour un exemple d'IPv6 tel que 2001:db8:1200::/48 lorsque le bon ASN et la longueur de préfixe autorisée sont utilisés.
Un résultat valide est un signal positif, mais il ne doit pas être interprété comme une garantie complète. Le chemin peut encore avoir un itinéraire incorrect, une mauvaise réputation commerciale, une description de registre obsolète ou un problème opérationnel en dehors de l'autorisation d'origine. Les opérateurs de réseau combinent normalement RPKI avec la surveillance BGP, le filtrage des préfixes, les vérifications de registre et les procédures de réponse aux incidents.
Un statut Valide peut également changer lorsqu'il y a un changement de réseau. Si une entreprise déplace un préfixe vers un autre ASN, commence à annoncer une route plus spécifique, ou modifie son plan d'adressage, le ROA existant peut ne plus correspondre à l'annonce nouvelle. RPKI reflète les données d'autorisation actuelles, il doit donc être maintenu en tant que partie des opérations normales du réseau.
Qu'est-ce que RPKI invalide signifie-t-il ?
Un itinéraire est RPKI non valide lorsqu'une autorisation applicable existe, mais que l'annonce BGP entre en conflit avec celle-ci. Le conflit implique généralement l'une des deux choses : l'ASN d'origine n'est pas autorisé, ou le préfixe annoncé est plus spécifique que la longueur maximale autorisée par le ROA.
Par exemple, un ROA peut autoriser AS64500 provenir 198.51.100.0/24. Si AS64510 annonce que ce même préfixe, l'ASN d'origine ne correspond pas et la route devient invalide. Le résultat peut également survenir lorsque AS64500 est autorisé pour le /24 mais annonce 198.51.100.0/25 alors que la ROA n'autorise pas les préfixes qui sont spécifiques.
Une route non valide ne signifie pas nécessairement qu'une usurpation malveillante est en cours. De nombreuses routes non valides sont causées par des erreurs opérationnelles ordinaires. Un ingénieur peut oublier de mettre à jour un ROA après une migration d'ASN, un fournisseur peut annoncer un préfixe client avec l'origine incorrecte, ou le réseau peut commencer à utiliser des préfixes plus spécifiques sans modifier la longueur maximale.
En même temps, un résultat non valide ne doit pas être ignoré. Il peut indiquer une annonce non autorisée, une fuite de route impliquant une origine inattendue, ou une erreur de configuration qui peut rendre le préfixe inaccessible via les réseaux utilisant un filtrage strict RPKI. La réponse correcte est d'enquêter rapidement sur le résultat et de le comparer au design de routage prévu.
Que signifie "RPKI non trouvé" ?
Un itinéraire est RPKI non trouvé lorsque le validateur ne parvient pas à trouver un ROA applicable pour le préfixe annoncé. Il n'existe aucune autorisation publiée pouvant confirmer ou nier l'ASN d'origine pour cette route.
Non trouvé est parfois appelé « inconnu », car le système de validation n'a pas assez d'informations d'autorisation pour arriver à une conclusion. Cela ne signifie pas que le chemin est invalide, et cela ne prouve pas que l'origine n'est pas autorisée. De nombreux préfixes légitimes sur Internet n'ont toujours pas de ROA, soit parce que le titulaire des ressources n'a pas encore créé de ROA, soit parce que l'autorisation n'est pas encore visible pour le validateur.
L'absence d'une ROA réduit la quantité d'informations disponibles pour les réseaux souhaitant valider le chemin. Si un ASN non autorisé annonce le même préfixe, un réseau voyant les deux annonces peut avoir des difficultés à distinguer le chemin légitime du faux uniquement avec RPKI.
Les détenteurs de ressources devraient normalement publier des ROA précis pour les préfixes qu'ils annoncent publiquement, en particulier lorsqu'ils prennent en charge des services importants. Cependant, les opérateurs devraient éviter de créer une autorisation hâtive ou trop large uniquement pour transformer « Not Found » en « Valid ». Un ROA mal configuré peut rendre une route légale invalide, ce qui peut avoir un impact opérationnel plus immédiat.
La différence entre invalide et non trouvé
La distinction la plus importante est que Invalid est un conflit, pendant que Non trouvé est l'absence de données d'autorisation. Invalide signifie que le validateur a trouvé un ROA pertinent mais que la route ne correspond pas à celui-ci. Non trouvé signifie qu'aucun ROA applicable n'a été trouvé.
Considérons deux exemples. Dans le premier, une entreprise publie un ROA autorisant AS64500 pour 192.0.2.0/24, mais AS64510 annonce le préfixe. La route est invalide car l'origine entre en conflit avec l'autorisation. Dans le deuxième cas, l'entreprise n'a publié aucun ROA, et AS64500 annonce le préfixe. La route n'est pas trouvée car il n'y a pas d'autorisation pour l'évaluer.
Cette différence est importante lors de la création de la politique de routage. De nombreux réseaux accordent un traitement particulier aux itinéraires non valides, car une autorisation existante indique que le détenteur de la ressource a exprimé une attente spécifique. Les itinéraires Non trouvés peuvent être surveillés, avoir une préférence plus faible ou être acceptés selon la politique locale. Chaque réseau décide comment appliquer le résultat.
Les opérateurs de réseau devraient également se rappeler que les résultats de validation peuvent varier temporairement pendant que les dépôts et les validateurs se mettent à jour. Si un ROA a été créé ou modifié il y a quelques minutes seulement, différents outils peuvent afficher des états différents jusqu'à ce que la mise à jour soit propagée dans le système de validation.
Pourquoi une route légale peut-elle devenir invalide ?
La cause la plus courante est un changement d'ASN. Une entreprise peut initialement annoncer un préfixe à partir d'un ASN fourni par une organisation de transit ou sponsorisante, puis déplacer ultérieurement le préfixe vers son propre ASN. Si le ROA autorise toujours l'ancienne origine, l'annonce nouvelle devient invalide.
Une deuxième cause est une longueur maximale de préfixe incorrecte. Une organisation peut détenir un /20, publier un ROA d'une longueur maximale de /20, et plus tard annoncer deux /21 chemins pour l'ingénierie du trafic. Ces annonces plus spécifiques ne sont peut-être pas couvertes par l'autorisation originale. La configuration BGP peut être intentionnelle, mais la politique RPKI est trop restrictive pour le nouveau design.
Les transferts IPv4 peuvent créer des problèmes similaires. Pendant un transfert, le détenteur administratif et l'origine de la routage peuvent changer à des moments différents. Si l'autorisation du précédent détenteur reste active alors que le nouveau détenteur annonce le préfixe depuis un ASN différent, la transition peut produire un état non valide.
Enregistrements obsolètes, limites de réseau incorrectes et mauvaises compréhensions du rôle du fournisseur de transit sont d'autres causes fréquentes. Un fournisseur peut transporter une route client sans être l'ASN d'origine. Le ROA a normalement besoin d'autoriser l'ASN qui apparaît comme origine de la route, et non simplement le transporteur qui transporte le trafic.
Comment dépanner un résultat RPKI non valide
Commencez par enregistrer le préfixe exact et l'ASN d'origine affichés dans l'annonce BGP. Ne vous fiez pas à une visualisation raccourcie ou à un document de configuration antérieur. Confirmez la famille d'adresses, la longueur du préfixe et l'origine observée par au moins un moniteur de routage fiable.
Ensuite, inspectez les ROAs actifs pour cette préfixe. Vérifiez l'ASN autorisé et la longueur maximale de préfixe. Si l'ASN d'origine ne correspond pas, déterminez si la route ou l'autorisation est incorrecte. Si l'ASN est correcte, vérifiez si le préfixe annoncé est plus spécifique que la longueur maximale autorisée.
Puis examinez les modifications récentes. Recherchez une migration ASN, un changement de fournisseur amont, un transfert IPv4, un déploiement IPv6, un déplacement de centre de données, un changement d'agrégation de route ou une mise à jour de politique BGP. La plupart des résultats Invalid légitimes peuvent être liés à une modification récente qui n'a pas été reflétée dans la gestion RPKI.
Si l'ROA est incorrect, mettez-le à jour via le registre régional Internet concerné, le LIR parrainant ou le système de gestion RPKI. Si l'annonce BGP est incorrecte, corrigez plutôt la politique de routage. Ne résolvez pas une erreur de routage en publiant un ROA inutilement large, car cela pourrait autoriser des annonces qui n'avaient jamais été prévues.
Après avoir apporté la correction, laissez un délai pour que le dépôt et le validateur se rafraîchissent. Vérifiez à nouveau le résultat en utilisant un service de validation externe et une source de surveillance BGP. La route doit revenir à Valide lorsque l'origine et la longueur du préfixe correspondent à l'autorisation publiée.
Comment les résultats RPKI affectent-ils le routage BGP
La validation RPKI ne retire pas automatiquement une route du réseau Internet. Le réseau récepteur décide comment utiliser les résultats dans sa politique de routage. Certains opérateurs rejettent les routes non valides, tandis que d'autres les marquent avec une préférence plus faible, génèrent des alertes ou continuent à les accepter sous certaines conditions.
Un itinéraire valide peut recevoir un traitement normal, mais il compete toujours avec les autres itinéraires selon la préférence locale, la longueur du chemin, les règles d'ingénierie de trafic et la politique du fournisseur. Un itinéraire Non trouvé peut être accepté par un réseau et traité avec plus de prudence par un autre. Un itinéraire non valide peut rester visible auprès de certains fournisseurs tout en devenant inatteignable auprès des réseaux qui appliquent des filtres stricts.
Cette différence explique pourquoi une annonce invalide peut causer une connectivité partielle. Un service peut fonctionner depuis une région mais échouer depuis une autre, car différentes réseaux appliquent différentes politiques. Lors de la diagnostic d'une panne, il est donc utile de comparer l'état de validation avec la visibilité BGP depuis plusieurs emplacements.
RPKI doit être considéré comme une entrée parmi d'autres dans la politique de routage, et non comme un remplacement universel des filtres de préfixe ou de la surveillance des routes. Les meilleurs résultats opérationnels proviennent généralement de la combinaison de données RPKI précises avec des registres et des enregistrements de routage soigneusement maintenus.
RPKI Validation for IPv4 and IPv6
Les mêmes trois états s'appliquent aux deux familles d'adresses IPv4 et IPv6. Dans chaque famille d'adresses, le validateur compare le préfixe annoncé, l'ASN d'origine et la longueur de préfixe autorisée avec les ROAs disponibles.
Les opérations IPv4 impliquent souvent des préfixes relativement petits, des transferts, des arrangements de location et plusieurs fournisseurs. Un changement de l'ASN d'origine ou l'utilisation d'annonces plus spécifiques peut rapidement affecter le résultat de la validation. Les détenteurs de ressources IPv4 devraient examiner le RPKI chaque fois qu'un bloc est transféré, loué, déplacé entre des fournisseurs ou annoncé depuis une nouvelle localisation.
Les réseaux IPv6 reçoivent souvent des allocations plus importantes et peuvent annoncer un agrégat tout en utilisant des sous-réseaux internes plus petits. Le ROA public doit correspondre aux préfixes qui sont réellement annoncés à Internet. Si un opérateur IPv6 autorise uniquement un agrégat mais annonce ultérieurement des routes plus spécifiques, ces routes peuvent devenir non valides à moins que la longueur maximale ne les autorise.
A larger IPv6 address space does not remove the need for origin validation. IPv6 route hijacks and configuration mistakes can still interrupt services. Publishing precise ROAs during the initial IPv6 deployment makes future troubleshooting easier and gives upstream networks a clear authorization signal.
Comment vérifier l'état RPKI avant un changement de réseau
Avant de modifier un ASN, un fournisseur amont, un plan d'agrégation de route ou un détenteur de ressources d'adresse, enregistrez l'état actuel de RPKI. Confirmez quel ASN origine actuellement le préfixe et si l'annonce est Valide, Non valide ou Introuvable.
Après avoir préparé le nouveau design de routage, comparez l'origine attendue et les longueurs de préfixe avec les ROAs planifiés. Si l'origine va changer, publiez ou mettez à jour l'autorisation avant d'annoncer la nouvelle route, chaque fois que l'emploi du temps opérationnel le permet. Pendant une migration contrôlée, une autorisation temporaire pour les deux origines peut être appropriée, mais l'arrangement doit être documenté et l'ancienne autorisation supprimée lorsque la transition est terminée.
Un pré-controle technique peut également révéler des incohérences liées. Le Vérificateur de disponibilité des ressources IP peut aider à examiner les informations du registre public, les données de l'ASN d'origine, les objets de routage, l'état RPKI et la visibilité BGP pour un préfixe IPv4 ou IPv6 public. C'est un contrôle technique plutôt qu'une preuve de propriété ou d'éligibilité à la transmission, donc la vérification contractuelle et du registre reste nécessaire.
Questions fréquemment posées sur l'état RPKI
Est-ce que « RPKI Not Found » est la même chose que « Invalid » ?
Non trouvé signifie qu'aucune ROA applicable n'a été trouvée. Invalide signifie qu'une ROA pertinente existe mais que l'annonce BGP entre en conflit avec celle-ci. Invalide nécessite généralement une enquête plus urgente, car cela représente un désaccord direct avec l'autorisation publiée.
Un itinéraire valide peut-il avoir un problème ?
Oui. Valide ne confirme que l'ASN d'origine et la longueur du préfixe correspondent à un ROA applicable. Il ne vérifie pas chaque partie du chemin BGP, la sécurité de l'application, la réputation de l'IP, la propriété légale ou la disponibilité du service.
Pourquoi mon itinéraire est-il invalide après avoir changé de fournisseur ?
Modifier le fournisseur seul ne nécessite pas nécessairement un nouveau ROA si l'ASN d'origine reste identique. Cependant, si le changement de fournisseur modifie également l'ASN d'origine, ou si le nouveau fournisseur annonce une longueur de préfixe différente, le ROA peut nécessiter une mise à jour.
Combien de temps faut-il pour qu'un changement ROA soit visible ?
Le changement doit être publié par le système RPKI concerné et récupéré par les validateurs. Il est courant qu'un court délai se produise. Lors d'un changement de production, vérifiez plus d'une source de validation et laissez un délai pour les intervalles de rafraîchissement.
Dois-je rejeter toutes les routes introuvables ?
Cela dépend de votre politique réseau et de votre modèle de risque. Le message « Not Found » ne prouve pas qu'un chemin soit incorrect. De nombreux chemins légitimes n'ont pas de ROA. Certaines réseaux acceptent les chemins « Not Found » tout en appliquant une surveillance ou une préférence plus faible ; d'autres utilisent des politiques plus strictes pour certains environnements.
L'RPKI peut-il protéger à la fois IPv4 et IPv6 ?
Oui. RPKI prend en charge l'autorisation d'origine pour les deux familles d'adresses. La configuration pratique doit correspondre aux préfixes et aux longueurs de préfixe que chaque réseau annonce réellement.
Les étiquettes d'état RPKI deviennent beaucoup plus faciles à comprendre lorsque l'on se souvient de la différence fondamentale entre l'autorisation et l'observation. Un résultat Valide signifie que la route correspond à une autorisation publiée. Un résultat Invalide signifie que la route est en conflit avec une autorisation applicable. Un résultat Non trouvé signifie qu'aucune autorisation n'était disponible pour que le validateur la vérifie.
Ces résultats sont particulièrement importants lors des migrations ASN, des changements de fournisseur, des transferts IPv4, des déploiements IPv6 et des redéfinitions de réseau. Une route légitime peut devenir invalide lorsque l'origine BGP change mais que le ROA n'est pas mis à jour, ou lorsque le réseau commence à annoncer des préfixes plus spécifiques que la longueur maximale autorisée.
Pour des opérations fiables, examinez ensemble le préfixe annoncé, l'ASN d'origine et la longueur maximale du préfixe. Maintenez les enregistrements RPKI alignés avec le design de routage réel, surveillez les changements après publication et enquêtez rapidement sur les résultats invalides. Utilisez RPKI en complément des enregistrements de registre, de la surveillance BGP, des données IRR et de la gestion documentée des changements, plutôt que de le considérer comme une substitution complète de ces systèmes.
Si vous souhaitez continuer la série, l'article suivant utile est Comment corriger une route RPKI non valide, qui peut expliquer en détail la planification de la migration, les autorisations superposées, les changements de fournisseur et les vérifications pratiques de validation.