Le rôle de RPKI dans le renforcement de la sécurité du routage mondial
RPKI aide les réseaux à repérer des origines non autorisées. Son effet dépend des preuves publiées, des vérifications locales et des politiques réellement appliquées.
Une erreur de routage dans un réseau peut toucher des utilisateurs très éloignés. Une origine incorrecte se propage, et un site pourtant en état de marche devient inaccessible, ou le trafic prend une direction inattendue. RPKI permet au réseau destinataire de vérifier une partie de l’annonce avant de s’y fier.
Cette protection dépend d’une chaîne : le détenteur publie une autorisation utilisable, un logiciel la vérifie et un opérateur applique une politique de routage. Suivre ces étapes permet de comprendre où la protection agit et où elle peut échouer.
Quelle affirmation vérifie-t-on ?
Les réseaux échangent leurs informations d’accessibilité avec BGP. Un préfixe désigne un bloc d’adresses IP ; un ASN identifie un système autonome. Une autorisation d’origine de route, ou ROA, indique quel ASN le détenteur autorise à être à l’origine de routes pour les préfixes indiqués.
Le logiciel de validation contrôle les certificats et les enregistrements signés, puis fournit les données d’autorisation. Le routeur compare l’origine et la longueur du préfixe annoncé avec ces données. Son opérateur décide de la conduite à tenir. Publication, validation des preuves et décision de routage restent des fonctions distinctes.
Trois résultats à ne pas confondre
- Valid : une autorisation couvrante permet au moins cette combinaison d’origine et de longueur.
- Invalid : des autorisations couvrent le préfixe, mais aucune ne permet cette combinaison.
- NotFound : les données utilisées ne contiennent aucune autorisation couvrant la route.
Le RFC 6811 définit ces règles. L’absence d’une ROA couvrante n’est donc pas un état Invalid. Et Valid ne signifie pas que tout le chemin annoncé a été authentifié.
La protection prend effet dans chaque réseau
Un réseau configuré pour rejeter les annonces Invalid peut arrêter une origine incompatible avec les autorisations au lieu de la propager. L’effet dépend des enregistrements, des données disponibles et de la politique effectivement déployée. Publier davantage de ROA et voir davantage de réseaux pratiquer la validation d’origine sont deux formes d’adoption différentes.
Le RFC 8481 distingue explicitement l’attribution d’un état de validation de l’action qui en découle. Aucun interrupteur mondial ne fait appliquer instantanément la même politique à tous les réseaux.
Une route divulguée à tort peut conserver une origine autorisée. Un chemin falsifié peut également préserver cette valeur. La validation d’origine laisse donc subsister des risques importants ; d’autres contrôles et une visibilité sur la propagation des routes restent nécessaires.
Il faut aussi entretenir le système de preuve
Une autorisation qui désigne le mauvais ASN ou exclut une longueur prévue peut rendre Invalid une annonce voulue. Des problèmes de certificat, de dépôt ou de logiciel peuvent aussi modifier les données disponibles. Les caches et les délais de mise à jour diffèrent : tous les réseaux ne voient pas forcément la même situation au même moment.
La préparation passe par des autorisations précises, des changements testés, des validateurs surveillés et une réponse prévue aux données absentes ou périmées. Un second validateur n’apporte que la diversité réelle de ses dépendances. Le RFC 7115 traite de l’exploitation ; le RFC 8211 examine les actions préjudiciables dans les systèmes de certification et de publication.
Une protection ne doit pas créer une tutelle sans fin
La question est aussi institutionnelle. En contrôlant des éléments de preuve essentiels, une organisation peut influencer des réseaux qu’elle n’exploite pas et dont elle ne représente pas politiquement les utilisateurs. Dans sa Note 28, Lu Heng défend une fonction de registre limitée à une administration exacte, sans en faire un instrument de coercition.
Sa Note 64, en anglais, propose des règles communes minimales, vérifiables localement, des données portables et une adoption volontaire des évolutions. La sécurité et la possibilité de remplacer un coordinateur défaillant doivent être conçues ensemble.
Après une coupure, découvrir qui contrôle un enregistrement indispensable devient une urgence. Mieux vaut suivre ces dépendances pendant que le réseau fonctionne. Le guide sur les conséquences d’une modification des données du registre, en anglais, montre comment un enregistrement peut conduire à un rejet de route.