La validation RPKI est maintenant une partie importante de la s\u00e9curit\u00e9 du routage BGP moderne. Elle permet aux op\u00e9rateurs de r\u00e9seau de d\u00e9terminer si un num\u00e9ro de syst\u00e8me autonome est autoris\u00e9 \u00e0 annoncer un pr\u00e9fixe IPv4 ou IPv6 particulier. Lorsqu'un routeur re\u00e7oit une annonce de route, il peut comparer l'annonce avec l'autorisation RPKI publi\u00e9e pour cette plage d'adresses.<\/p>\n\n\n\n
Le r\u00e9sultat est g\u00e9n\u00e9ralement affich\u00e9 comme Valide, Invalide ou Non trouv\u00e9. Ces trois \u00e9tiquettes sont simples, mais elles sont souvent mal comprises. Un r\u00e9sultat Valide ne signifie pas que chaque partie du chemin est parfaite. Un r\u00e9sultat Invalide ne signifie pas toujours qu'une attaque est en cours sur le r\u00e9seau. Un r\u00e9sultat Non trouv\u00e9 ne signifie pas automatiquement que l'annonce est dangereuse.<\/p>\n\n\n\n
Les \u00e9tiquettes d\u00e9crivent uniquement la relation entre une annonce BGP et les donn\u00e9es d'autorisation d'origine de route disponibles. Pour comprendre correctement le r\u00e9sultat, vous devez comparer trois \u00e9l\u00e9ments : le pr\u00e9fixe IP annonc\u00e9, l'ASN d'origine et la longueur maximale de pr\u00e9fixe autoris\u00e9e par l'autorisation.<\/p>\n\n\n\n
Cet article explique chaque statut RPKI en termes pratiques, montre pourquoi les routes l\u00e9gitimes peuvent devenir Invalides, et fournit un processus de d\u00e9pannage pour les op\u00e9rateurs de r\u00e9seau g\u00e9rant leur propre ASN, leurs ressources IPv4, leurs allocations IPv6 ou leur routage en amont. Si vous \u00eates nouveau sur le sujet, commencez par notre guide vers Qu'est-ce que le RPKI ?<\/a> et puis lire Qu'est-ce qu'un ROA dans RPKI ?<\/a> pour une explication d\u00e9taill\u00e9e de l'enregistrement d'autorisation lui-m\u00eame.<\/p>\n\n\n\n RPKI signifie Infrastructure \u00e0 cl\u00e9 publique des ressources. Elle relie les ressources num\u00e9riques Internet aux enregistrements d'autorisation sign\u00e9s cryptographiquement. Le d\u00e9tenteur ou le gestionnaire autoris\u00e9 d'un pr\u00e9fixe IP peut publier un ROA indiquant qu'un AS particulier est autoris\u00e9 \u00e0 originer ce pr\u00e9fixe dans BGP.<\/p>\n\n\n\n Un validateur collecte ces enregistrements sign\u00e9s, v\u00e9rifie leur authenticit\u00e9 et cr\u00e9e un ensemble de donn\u00e9es valid\u00e9 pour les op\u00e9rateurs de r\u00e9seau. Lorsqu'un chemin BGP est re\u00e7u, le syst\u00e8me de routage de l'op\u00e9rateur compare ce chemin \u00e0 cet ensemble de donn\u00e9es. La comparaison pose trois questions fondamentales : la pr\u00e9fixe annonc\u00e9 est-il couvert par une autorisation ? Le ASN d'origine est-il celui indiqu\u00e9 dans cette autorisation ? La longueur du pr\u00e9fixe annonc\u00e9 est-elle inf\u00e9rieure ou \u00e9gale \u00e0 la longueur maximale autoris\u00e9e ?<\/p>\n\n\n\n La r\u00e9ponse \u00e0 ces questions produit l'\u00e9tat RPKI. Cet \u00e9tat s'applique \u00e0 l'autorisation d'origine des routes, et non \u00e0 chaque attribut du chemin BGP. RPKI ne prouve pas que tous les r\u00e9seaux interm\u00e9diaires sont corrects, que le trafic suivra le meilleur chemin, ou que les ressources d'adresses sont l\u00e9galement disponibles pour la vente. C'est un signal de s\u00e9curit\u00e9 cibl\u00e9 qui am\u00e9liore la confiance dans l'origine d'une route.<\/p>\n\n\n\n Un itin\u00e9raire est Valide RPKI<\/strong> lorsque l'annonce BGP est couverte par au moins une ROA applicable, l'ASN d'origine correspond \u00e0 l'ASN autoris\u00e9, et la longueur du pr\u00e9fixe annonc\u00e9 est autoris\u00e9e par la longueur maximale de la ROA. En termes pratiques, la route est coh\u00e9rente avec l'autorisation de routage publi\u00e9e par le d\u00e9tenteur des ressources.<\/p>\n\n\n\n Par exemple, supposons qu'une entreprise contr\u00f4le Un r\u00e9sultat valide est un signal positif, mais il ne doit pas \u00eatre interpr\u00e9t\u00e9 comme une garantie compl\u00e8te. Le chemin peut encore avoir un itin\u00e9raire incorrect, une mauvaise r\u00e9putation commerciale, une description de registre obsol\u00e8te ou un probl\u00e8me op\u00e9rationnel en dehors de l'autorisation d'origine. Les op\u00e9rateurs de r\u00e9seau combinent normalement RPKI avec la surveillance BGP, le filtrage des pr\u00e9fixes, les v\u00e9rifications de registre et les proc\u00e9dures de r\u00e9ponse aux incidents.<\/p>\n\n\n\n Un statut Valide peut \u00e9galement changer lorsqu'il y a un changement de r\u00e9seau. Si une entreprise d\u00e9place un pr\u00e9fixe vers un autre ASN, commence \u00e0 annoncer une route plus sp\u00e9cifique, ou modifie son plan d'adressage, le ROA existant peut ne plus correspondre \u00e0 l'annonce nouvelle. RPKI refl\u00e8te les donn\u00e9es d'autorisation actuelles, il doit donc \u00eatre maintenu en tant que partie des op\u00e9rations normales du r\u00e9seau.<\/p>\n\n\n\n Un itin\u00e9raire est RPKI non valide<\/strong> lorsqu'une autorisation applicable existe, mais que l'annonce BGP entre en conflit avec celle-ci. Le conflit implique g\u00e9n\u00e9ralement l'une des deux choses : l'ASN d'origine n'est pas autoris\u00e9, ou le pr\u00e9fixe annonc\u00e9 est plus sp\u00e9cifique que la longueur maximale autoris\u00e9e par le ROA.<\/p>\n\n\n\n Par exemple, un ROA peut autoriser Une route non valide ne signifie pas n\u00e9cessairement qu'une usurpation malveillante est en cours. De nombreuses routes non valides sont caus\u00e9es par des erreurs op\u00e9rationnelles ordinaires. Un ing\u00e9nieur peut oublier de mettre \u00e0 jour un ROA apr\u00e8s une migration d'ASN, un fournisseur peut annoncer un pr\u00e9fixe client avec l'origine incorrecte, ou le r\u00e9seau peut commencer \u00e0 utiliser des pr\u00e9fixes plus sp\u00e9cifiques sans modifier la longueur maximale.<\/p>\n\n\n\n En m\u00eame temps, un r\u00e9sultat non valide ne doit pas \u00eatre ignor\u00e9. Il peut indiquer une annonce non autoris\u00e9e, une fuite de route impliquant une origine inattendue, ou une erreur de configuration qui peut rendre le pr\u00e9fixe inaccessible via les r\u00e9seaux utilisant un filtrage strict RPKI. La r\u00e9ponse correcte est d'enqu\u00eater rapidement sur le r\u00e9sultat et de le comparer au design de routage pr\u00e9vu.<\/p>\n\n\n\n Un itin\u00e9raire est RPKI non trouv\u00e9<\/strong> lorsque le validateur ne parvient pas \u00e0 trouver un ROA applicable pour le pr\u00e9fixe annonc\u00e9. Il n'existe aucune autorisation publi\u00e9e pouvant confirmer ou nier l'ASN d'origine pour cette route.<\/p>\n\n\n\n Non trouv\u00e9 est parfois appel\u00e9 \u00ab inconnu \u00bb, car le syst\u00e8me de validation n'a pas assez d'informations d'autorisation pour arriver \u00e0 une conclusion. Cela ne signifie pas que le chemin est invalide, et cela ne prouve pas que l'origine n'est pas autoris\u00e9e. De nombreux pr\u00e9fixes l\u00e9gitimes sur Internet n'ont toujours pas de ROA, soit parce que le titulaire des ressources n'a pas encore cr\u00e9\u00e9 de ROA, soit parce que l'autorisation n'est pas encore visible pour le validateur.<\/p>\n\n\n\n L'absence d'une ROA r\u00e9duit la quantit\u00e9 d'informations disponibles pour les r\u00e9seaux souhaitant valider le chemin. Si un ASN non autoris\u00e9 annonce le m\u00eame pr\u00e9fixe, un r\u00e9seau voyant les deux annonces peut avoir des difficult\u00e9s \u00e0 distinguer le chemin l\u00e9gitime du faux uniquement avec RPKI.<\/p>\n\n\n\n Les d\u00e9tenteurs de ressources devraient normalement publier des ROA pr\u00e9cis pour les pr\u00e9fixes qu'ils annoncent publiquement, en particulier lorsqu'ils prennent en charge des services importants. Cependant, les op\u00e9rateurs devraient \u00e9viter de cr\u00e9er une autorisation h\u00e2tive ou trop large uniquement pour transformer \u00ab Not Found \u00bb en \u00ab Valid \u00bb. Un ROA mal configur\u00e9 peut rendre une route l\u00e9gale invalide, ce qui peut avoir un impact op\u00e9rationnel plus imm\u00e9diat.<\/p>\n\n\n\n La distinction la plus importante est que Invalid est un conflit<\/strong>, pendant que Non trouv\u00e9 est l'absence de donn\u00e9es d'autorisation<\/strong>. Invalide signifie que le validateur a trouv\u00e9 un ROA pertinent mais que la route ne correspond pas \u00e0 celui-ci. Non trouv\u00e9 signifie qu'aucun ROA applicable n'a \u00e9t\u00e9 trouv\u00e9.<\/p>\n\n\n\n Consid\u00e9rons deux exemples. Dans le premier, une entreprise publie un ROA autorisant Cette diff\u00e9rence est importante lors de la cr\u00e9ation de la politique de routage. De nombreux r\u00e9seaux accordent un traitement particulier aux itin\u00e9raires non valides, car une autorisation existante indique que le d\u00e9tenteur de la ressource a exprim\u00e9 une attente sp\u00e9cifique. Les itin\u00e9raires Non trouv\u00e9s peuvent \u00eatre surveill\u00e9s, avoir une pr\u00e9f\u00e9rence plus faible ou \u00eatre accept\u00e9s selon la politique locale. Chaque r\u00e9seau d\u00e9cide comment appliquer le r\u00e9sultat.<\/p>\n\n\n\n Les op\u00e9rateurs de r\u00e9seau devraient \u00e9galement se rappeler que les r\u00e9sultats de validation peuvent varier temporairement pendant que les d\u00e9p\u00f4ts et les validateurs se mettent \u00e0 jour. Si un ROA a \u00e9t\u00e9 cr\u00e9\u00e9 ou modifi\u00e9 il y a quelques minutes seulement, diff\u00e9rents outils peuvent afficher des \u00e9tats diff\u00e9rents jusqu'\u00e0 ce que la mise \u00e0 jour soit propag\u00e9e dans le syst\u00e8me de validation.<\/p>\n\n\n\n La cause la plus courante est un changement d'ASN. Une entreprise peut initialement annoncer un pr\u00e9fixe \u00e0 partir d'un ASN fourni par une organisation de transit ou sponsorisante, puis d\u00e9placer ult\u00e9rieurement le pr\u00e9fixe vers son propre ASN. Si le ROA autorise toujours l'ancienne origine, l'annonce nouvelle devient invalide.<\/p>\n\n\n\n Une deuxi\u00e8me cause est une longueur maximale de pr\u00e9fixe incorrecte. Une organisation peut d\u00e9tenir un Les transferts IPv4 peuvent cr\u00e9er des probl\u00e8mes similaires. Pendant un transfert, le d\u00e9tenteur administratif et l'origine de la routage peuvent changer \u00e0 des moments diff\u00e9rents. Si l'autorisation du pr\u00e9c\u00e9dent d\u00e9tenteur reste active alors que le nouveau d\u00e9tenteur annonce le pr\u00e9fixe depuis un ASN diff\u00e9rent, la transition peut produire un \u00e9tat non valide.<\/p>\n\n\n\n Enregistrements obsol\u00e8tes, limites de r\u00e9seau incorrectes et mauvaises compr\u00e9hensions du r\u00f4le du fournisseur de transit sont d'autres causes fr\u00e9quentes. Un fournisseur peut transporter une route client sans \u00eatre l'ASN d'origine. Le ROA a normalement besoin d'autoriser l'ASN qui appara\u00eet comme origine de la route, et non simplement le transporteur qui transporte le trafic.<\/p>\n\n\n\n Commencez par enregistrer le pr\u00e9fixe exact et l'ASN d'origine affich\u00e9s dans l'annonce BGP. Ne vous fiez pas \u00e0 une visualisation raccourcie ou \u00e0 un document de configuration ant\u00e9rieur. Confirmez la famille d'adresses, la longueur du pr\u00e9fixe et l'origine observ\u00e9e par au moins un moniteur de routage fiable.<\/p>\n\n\n\n Ensuite, inspectez les ROAs actifs pour cette pr\u00e9fixe. V\u00e9rifiez l'ASN autoris\u00e9 et la longueur maximale de pr\u00e9fixe. Si l'ASN d'origine ne correspond pas, d\u00e9terminez si la route ou l'autorisation est incorrecte. Si l'ASN est correcte, v\u00e9rifiez si le pr\u00e9fixe annonc\u00e9 est plus sp\u00e9cifique que la longueur maximale autoris\u00e9e.<\/p>\n\n\n\n Puis examinez les modifications r\u00e9centes. Recherchez une migration ASN, un changement de fournisseur amont, un transfert IPv4, un d\u00e9ploiement IPv6, un d\u00e9placement de centre de donn\u00e9es, un changement d'agr\u00e9gation de route ou une mise \u00e0 jour de politique BGP. La plupart des r\u00e9sultats Invalid l\u00e9gitimes peuvent \u00eatre li\u00e9s \u00e0 une modification r\u00e9cente qui n'a pas \u00e9t\u00e9 refl\u00e9t\u00e9e dans la gestion RPKI.<\/p>\n\n\n\n Si l'ROA est incorrect, mettez-le \u00e0 jour via le registre r\u00e9gional Internet concern\u00e9, le LIR parrainant ou le syst\u00e8me de gestion RPKI. Si l'annonce BGP est incorrecte, corrigez plut\u00f4t la politique de routage. Ne r\u00e9solvez pas une erreur de routage en publiant un ROA inutilement large, car cela pourrait autoriser des annonces qui n'avaient jamais \u00e9t\u00e9 pr\u00e9vues.<\/p>\n\n\n\n Apr\u00e8s avoir apport\u00e9 la correction, laissez un d\u00e9lai pour que le d\u00e9p\u00f4t et le validateur se rafra\u00eechissent. V\u00e9rifiez \u00e0 nouveau le r\u00e9sultat en utilisant un service de validation externe et une source de surveillance BGP. La route doit revenir \u00e0 Valide lorsque l'origine et la longueur du pr\u00e9fixe correspondent \u00e0 l'autorisation publi\u00e9e.<\/p>\n\n\n\n La validation RPKI ne retire pas automatiquement une route du r\u00e9seau Internet. Le r\u00e9seau r\u00e9cepteur d\u00e9cide comment utiliser les r\u00e9sultats dans sa politique de routage. Certains op\u00e9rateurs rejettent les routes non valides, tandis que d'autres les marquent avec une pr\u00e9f\u00e9rence plus faible, g\u00e9n\u00e8rent des alertes ou continuent \u00e0 les accepter sous certaines conditions.<\/p>\n\n\n\n Un itin\u00e9raire valide peut recevoir un traitement normal, mais il compete toujours avec les autres itin\u00e9raires selon la pr\u00e9f\u00e9rence locale, la longueur du chemin, les r\u00e8gles d'ing\u00e9nierie de trafic et la politique du fournisseur. Un itin\u00e9raire Non trouv\u00e9 peut \u00eatre accept\u00e9 par un r\u00e9seau et trait\u00e9 avec plus de prudence par un autre. Un itin\u00e9raire non valide peut rester visible aupr\u00e8s de certains fournisseurs tout en devenant inatteignable aupr\u00e8s des r\u00e9seaux qui appliquent des filtres stricts.<\/p>\n\n\n\n Cette diff\u00e9rence explique pourquoi une annonce invalide peut causer une connectivit\u00e9 partielle. Un service peut fonctionner depuis une r\u00e9gion mais \u00e9chouer depuis une autre, car diff\u00e9rentes r\u00e9seaux appliquent diff\u00e9rentes politiques. Lors de la diagnostic d'une panne, il est donc utile de comparer l'\u00e9tat de validation avec la visibilit\u00e9 BGP depuis plusieurs emplacements.<\/p>\n\n\n\n RPKI doit \u00eatre consid\u00e9r\u00e9 comme une entr\u00e9e parmi d'autres dans la politique de routage, et non comme un remplacement universel des filtres de pr\u00e9fixe ou de la surveillance des routes. Les meilleurs r\u00e9sultats op\u00e9rationnels proviennent g\u00e9n\u00e9ralement de la combinaison de donn\u00e9es RPKI pr\u00e9cises avec des registres et des enregistrements de routage soigneusement maintenus.<\/p>\n\n\n\n Les m\u00eames trois \u00e9tats s'appliquent aux deux familles d'adresses IPv4 et IPv6. Dans chaque famille d'adresses, le validateur compare le pr\u00e9fixe annonc\u00e9, l'ASN d'origine et la longueur de pr\u00e9fixe autoris\u00e9e avec les ROAs disponibles.<\/p>\n\n\n\n Les op\u00e9rations IPv4 impliquent souvent des pr\u00e9fixes 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\u00e9cifiques peut rapidement affecter le r\u00e9sultat de la validation. Les d\u00e9tenteurs de ressources IPv4 devraient examiner le RPKI chaque fois qu'un bloc est transf\u00e9r\u00e9, lou\u00e9, d\u00e9plac\u00e9 entre des fournisseurs ou annonc\u00e9 depuis une nouvelle localisation.<\/p>\n\n\n\n Les r\u00e9seaux IPv6 re\u00e7oivent souvent des allocations plus importantes et peuvent annoncer un agr\u00e9gat tout en utilisant des sous-r\u00e9seaux internes plus petits. Le ROA public doit correspondre aux pr\u00e9fixes qui sont r\u00e9ellement annonc\u00e9s \u00e0 Internet. Si un op\u00e9rateur IPv6 autorise uniquement un agr\u00e9gat mais annonce ult\u00e9rieurement des routes plus sp\u00e9cifiques, ces routes peuvent devenir non valides \u00e0 moins que la longueur maximale ne les autorise.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Avant de modifier un ASN, un fournisseur amont, un plan d'agr\u00e9gation de route ou un d\u00e9tenteur de ressources d'adresse, enregistrez l'\u00e9tat actuel de RPKI. Confirmez quel ASN origine actuellement le pr\u00e9fixe et si l'annonce est Valide, Non valide ou Introuvable.<\/p>\n\n\n\n Apr\u00e8s avoir pr\u00e9par\u00e9 le nouveau design de routage, comparez l'origine attendue et les longueurs de pr\u00e9fixe avec les ROAs planifi\u00e9s. Si l'origine va changer, publiez ou mettez \u00e0 jour l'autorisation avant d'annoncer la nouvelle route, chaque fois que l'emploi du temps op\u00e9rationnel le permet. Pendant une migration contr\u00f4l\u00e9e, une autorisation temporaire pour les deux origines peut \u00eatre appropri\u00e9e, mais l'arrangement doit \u00eatre document\u00e9 et l'ancienne autorisation supprim\u00e9e lorsque la transition est termin\u00e9e.<\/p>\n\n\n\nQu'est-ce que la validation RPKI ?<\/h2>\n\n\n\n
Qu'est-ce que signifie RPKI valide ?<\/h2>\n\n\n\n
203.0.113.0\/24<\/code> et publie un ROA autorisant AS64500<\/code> originer cela \/24<\/code>. Si la compagnie annonce 203.0.113.0\/24<\/code> depuis AS64500<\/code>, l'annonce devrait retourner Valide. C'est \u00e9galement vrai pour un exemple d'IPv6 tel que 2001:db8:1200::\/48<\/code> lorsque le bon ASN et la longueur de pr\u00e9fixe autoris\u00e9e sont utilis\u00e9s.<\/p>\n\n\n\nQu'est-ce que RPKI invalide signifie-t-il ?<\/h2>\n\n\n\n
AS64500<\/code> provenir 198.51.100.0\/24<\/code>. Si AS64510<\/code> annonce que ce m\u00eame pr\u00e9fixe, l'ASN d'origine ne correspond pas et la route devient invalide. Le r\u00e9sultat peut \u00e9galement survenir lorsque AS64500<\/code> est autoris\u00e9 pour le \/24<\/code> mais annonce 198.51.100.0\/25<\/code> alors que la ROA n'autorise pas les pr\u00e9fixes qui sont sp\u00e9cifiques.<\/p>\n\n\n\nQue signifie \"RPKI non trouv\u00e9\" ?<\/h2>\n\n\n\n
La diff\u00e9rence entre invalide et non trouv\u00e9<\/h2>\n\n\n\n
AS64500<\/code> pour 192.0.2.0\/24<\/code>, mais AS64510<\/code> annonce le pr\u00e9fixe. La route est invalide car l'origine entre en conflit avec l'autorisation. Dans le deuxi\u00e8me cas, l'entreprise n'a publi\u00e9 aucun ROA, et AS64500<\/code> annonce le pr\u00e9fixe. La route n'est pas trouv\u00e9e car il n'y a pas d'autorisation pour l'\u00e9valuer.<\/p>\n\n\n\nPourquoi une route l\u00e9gale peut-elle devenir invalide ?<\/h2>\n\n\n\n
\/20<\/code>, publier un ROA d'une longueur maximale de \/20<\/code>, et plus tard annoncer deux \/21<\/code> chemins pour l'ing\u00e9nierie du trafic. Ces annonces plus sp\u00e9cifiques ne sont peut-\u00eatre pas couvertes par l'autorisation originale. La configuration BGP peut \u00eatre intentionnelle, mais la politique RPKI est trop restrictive pour le nouveau design.<\/p>\n\n\n\nComment d\u00e9panner un r\u00e9sultat RPKI non valide<\/h2>\n\n\n\n
Comment les r\u00e9sultats RPKI affectent-ils le routage BGP<\/h2>\n\n\n\n
RPKI Validation for IPv4 and IPv6<\/h2>\n\n\n\n
Comment v\u00e9rifier l'\u00e9tat RPKI avant un changement de r\u00e9seau<\/h2>\n\n\n\n